Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CDN vs S3

jdorfman.posthaven.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: CDN vs S3

#71

Post by noelwelsh »

currysausage wrote: post #42
jcastro wrote: post #12

Since this thread will likely turn into people asking about Cloudfront performance, does anyone have any real-world experience with CloudFront vs. Rackspace with Akamai CDN? On paper the Rackspace one looks like a great performance/price alternative.

I don't know about Cloudfront vs Rackspace+Akamai, however, based on some quick tests I did a year ago, I seem to recall that Rackspace+Akamai didn't deliver the same performance as professional Akamai services. In my experiments, Rackspace+Akamai used different servers, often located farther away, than big Akamai sites. (If anybody has background information about this, I would be very interested to hear.)

Rackspace CDN says this:

"Rackspace uses 213 of Akamai's edge locations, selected especially for our customers' typical usage patterns, and designed to cover all major areas of the globe." http://www.rackspace.com/cloud/files/

Akamai has approximately 5 gazillion edge locations, so yes, it is a cut down version. It is still a lot more POPs than just about every other CDN, though this doesn't necessarily translate into performance.

Re: CDN vs S3

#72

Post by jcampbell1 »

jefe78 wrote: post #66
jcampbell1 wrote: post #64

Earlier quoted context omitted.

I am sincerely not being spiteful. I am trying to warn you. Your company's unaudited financials state that there is only $7,000 in the bank. http://www.sec.gov/Archives/edgar/data/1499274/0001096350130... I sign my own paycheck, so the notion of whether he is overpaying is a bit confusing.

I'm entirely aware of the financial situation. How is calling my employer a pump and dump scam NOT spiteful when I've worked on this project from the beginning? Edit: Also, I don't appreciate you posting that. It's completely off-topic. Keep it classy.

At this point, the article has left hackernews. I am writing to you as fellow hacker looking to help you out.

You are involved in a stock fraud. The company you work for is a sham.

If you live in the US, then you have a plausible defense that you have no understanding of the underlying business. In this case, you likely can't afford the lawyer to present this case.

If you don't live in the US, then be careful. Imagine, ten years down the road, you are a successful engineer, and want to take your family to Disney world. Unfortunately, there is an outstanding bench warrant for your arrest, and rather than a nice family vacation that your wife wanted, you end up in a US prison.

Re: CDN vs S3

#73

Post by Kudos »

zwily wrote: post #33
jdorfman wrote: post #16

Earlier quoted context omitted.

@molecule obvious to you and I. I wrote this to inform those who think it is a good idea to use S3 as a CDN, that it isn't. If we can educate a few developers then we (this awesome community of hackers) are making the web faster.

Honest question: Do you actually know anyone that thinks S3 is appropriate as a CDN?

Tumblr and Twitter both used to, and I've met a bunch of developers at meetups who rather than think S3 is a CDN, do not understand what a CDN is.

Re: CDN vs S3

#75

Post by currysausage »

noelwelsh wrote: post #71
currysausage wrote: post #42

Earlier quoted context omitted.

I don't know about Cloudfront vs Rackspace+Akamai, however, based on some quick tests I did a year ago, I seem to recall that Rackspace+Akamai didn't deliver the same performance as professional Akamai services. In my experiments, Rackspace+Akamai used different servers, often located farther away, than big Akamai sites. (If anybody has background information about this, I would be very interested to hear.)

Rackspace CDN says this: "Rackspace uses 213 of Akamai's edge locations, selected especially for our customers' typical usage patterns, and designed to cover all major areas of the globe." http://www.rackspace.com/cloud/files/ Akamai has approximately 5 gazillion edge locations, so yes, it is a cut down version. It is still a lot more POPs than just about every other CDN, though this doesn't necessarily translate int…

Ah, thank you. That info wasn't there when I conducted the tests: http://web.archive.org/web/20120915095343/http://www.rackspa...?

"though this doesn't necessarily translate into performance" - Yes, even when the files were already cached, I wasn't always satisfied with the performance.

A detail that bugged me, by the way, was the high number of CNAME requests, although this should at worst affect the first view.

Re: CDN vs S3

#76

Post by nkoren »

jcampbell1 wrote: post #36
micro-ram wrote: post #32

Earlier quoted context omitted.

Both buffer while paused on Chrome iOS.

Chrome on iOS is probably using Apple's AVPlayer, which makes sense because there is probably no other way to access the dedicated decoding hardware. Apple is not afraid to Cache an HTTP 1.0 206 response.

Both are buffering fine for me on Chrome for Android, too.

Re: CDN vs S3

#77

Post by alinajaf »

amalag wrote: post #46
alinajaf wrote: post #24

> I think S3 is a great origin server for static assets Pro-tip: If you're using Rails, just create a distribution with your app as the origin server and in production.rb, set your asset host to your distributions host. You get the asset cache without having to do the precompile step. Tastes great with Heroku.

This is smart, I usually use the precompile with upload to S3 via asset_sync gem. Since Heroku will precompile by default, what do you do to disable it. Just turning on config.serve_static_assets = true is likely not enough.

> This is smart, I usually use the precompile with upload to S3 via asset_sync gem

I used to do the same until cloudfront rolled out custom origins.

> Since Heroku will precompile by default, what do you do to disable it.

I misspoke in my comment, what I meant was you can skip the synch with S3 step. I've never actually bothered to stop heroku precompiling assets (though I may as well). This question on SO looks promising:

http://stackoverflow.com/questions/8953360/preventing-heroku...

If you do that though, as you mentioned, you will definitely need to flip serve_static_assets on.

Re: CDN vs S3

#78

Post by alinajaf »

jere wrote: post #53

For everyone saying this is obvious: I'm one of those idiots that didn't quite get it and I appreciate this post a lot. For the past week, I've been working on writing a little static site generator and putting it on S3 and I thought I was pretty damn clever for finally getting around to doing that... except now it turns out I'm clueless yet again. I'm looking at Cloudfront now, but I'm still not sure if has all the…

I don't think you're an idiot, it's more likely that you were just unaware of cloudfront or perhaps CDNs in general.

S3 is for storing files, Cloudfront is for serving cached versions of them really quickly out of edge locations (i.e. the closest CDN datacentre to the user that requests it).

In your usecase, your best bet is to use them in combination. Set up a Cloudfront distribution to point to your S3 bucket, then setup DNS to point to your Cloudfront distribution.

One big point to note is that you need to either:

* Configure Cloudfront to expire objects after a TTL (time-to-live) that is reasonable to you (e.g. 1 hour, 1 day etc). You can do this from the Cloudfront 'new distribution' wizard.

OR

* Let Cloudfront respect HTTP headers and then make S3 (or whatever your custom origin is) set cache-control headers that make sense for how often you update your site. Not sure if/how you can do this with S3, with a custom origin its your app so you can set whatever http headers you like.

To be clear: if you don't do this, I'm pretty sure cloudfront caches things forever, or at least a very long time.

Personally, I think triggering cache invalidations should only be for emergencies (e.g. someone has uploaded questionable content to serve to other users and it's cached in at and edge). Rather than screwing around with that, save yourself some headaches: pick a sensible TTL and wait a little longer to have things up to date at your edges.

Note that by using Cloudfront in this manner, you get the performance benefit of serving static files. If performance at the expense of convenience was your main reason for going with static site generation, you might want to rethink that decision (there are other perfectly good reasons for wanting to use a static site generator, security being my favourite).

Do feel free to ping me over email if you have any questions on the above.

Re: CDN vs S3

#79

Post by jere »

alinajaf wrote: post #78
jere wrote: post #53

For everyone saying this is obvious: I'm one of those idiots that didn't quite get it and I appreciate this post a lot. For the past week, I've been working on writing a little static site generator and putting it on S3 and I thought I was pretty damn clever for finally getting around to doing that... except now it turns out I'm clueless yet again. I'm looking at Cloudfront now, but I'm still not sure if has all the…

I don't think you're an idiot, it's more likely that you were just unaware of cloudfront or perhaps CDNs in general. S3 is for storing files, Cloudfront is for serving cached versions of them really quickly out of edge locations (i.e. the closest CDN datacentre to the user that requests it). In your usecase, your best bet is to use them in combination. Set up a Cloudfront distribution to point to your S3 bucket, then…

>If performance at the expense of convenience was your main reason for going with static site generation, you might want to rethink that decision (there are other perfectly good reasons for wanting to use a static site generator, security being my favourite).

Great comment. I didn't get this part though. What would be a better alternative?

Performance is one of the main reasons I considered this (uptime is another). Let's just say I've had the same shared hosting for over 5 years and the speed/uptime have been a disappointment for a long time. When I was working on a site and noticed a 500kb background image was taking 2 seconds to load and around the same time I saw that the spotify homepage was streaming a fullscreen video instantly, that was kind of the last straw.

So I thought the idea was that skipping dynamic generation, using distribution (well, I think my assumption was S3 did have edge locations), and just having a better host was a big win.

Re: CDN vs S3

#80

Post by bonzoesc »

jere wrote: post #53

For everyone saying this is obvious: I'm one of those idiots that didn't quite get it and I appreciate this post a lot. For the past week, I've been working on writing a little static site generator and putting it on S3 and I thought I was pretty damn clever for finally getting around to doing that... except now it turns out I'm clueless yet again. I'm looking at Cloudfront now, but I'm still not sure if has all the…

You're not clueless. S3 is almost certainly good enough for what you're doing.
Post reply on HN