Re:Distribute Your Content With Amazon CloudFront
by ryanmahoski on Tuesday November 18, 2008 @02:41PM
(#368602)
I'm seeing 38% faster downloads from Phoenix (nearest CloudFront edge: L.A.). I ran 5 trials on a 178MB video hosted on S3 [1] and CloudFront [2]. The S3 GETs took: 6m02s, 1m50s, -failed after 28MB- , 2m01s, 2m04s. The CloudFront GETs took: 3m40s, 1m10s, 1m23s, 2m05s, 1m25s. Ignoring the failed S3 run, we can compare average client latency: 2m59s vs 1m50s.
Re:Distribute Your Content With Amazon CloudFront
by ryanmahoski on Tuesday November 18, 2008 @08:05PM
(#368980)
Yes that is interesting without being shocking. True we can't conclude anything from one spin so if you have time please run it again and share. If it was an anomaly then I think it's: a) merely verification that the pipes downstream are unreliable and/or b) your edge location didn't have the file cached so fetched from S3 before serving to you. But if you continue to see unexpected results do tell.
Re:Distribute Your Content With Amazon CloudFront
by lux on Tuesday November 18, 2008 @06:25PM
(#368896)
I wonder how this compares to Mosso's CloudFiles? They've already been offering a CDN built-in, but I haven't done any testing myself yet to compare their services (latency, etc).
Cost comparisons run very close using their cost calculators for just CloudFiles vs S3...
Re:Distribute Your Content With Amazon CloudFront
by xal on Tuesday November 18, 2008 @10:55PM
(#369106)
Are there any guarantees on how fast files are invalidated on the edge servers? Running curl on those urls gives a lot of insight ( X-Cache: MISS ... ) into what's going on but it seems that invalidation of resources take 10-15 seconds. The X-Cache changes immediately but you only get a miss after a while. At least that's what I've been seeing in my pretty trivial tests.
Re:Distribute Your Content With Amazon CloudFront
by crabapple on Wednesday November 19, 2008 @01:10AM
(#369236)
the point of a cdn is to give you an SLA and honor it. how they configure their delivery platform should be opaque to you, its not like you are going to be getting a shell on the cdn machines anyway
Re:Distribute Your Content With Amazon CloudFront
by briansmith on Tuesday November 18, 2008 @08:05AM
(#368188)
Signing up for a SSL certificate using your own credentials and then letting a third-party distribute and use your private key on an arbitrary number of systems you have no control over is bordering on fraud.
Re:Distribute Your Content With Amazon CloudFront
by zmimon on Tuesday November 18, 2008 @09:09PM
(#369030)
Hold on, who says you are handing over the private key?
I would definitely like to use a CDN with SSL sites. I am happy for the domain to be amazon's (or cloudfront, whatever) signed with their cert, I just don't want the browser security to be broken by having non-SSL content on the page.
Re:Distribute Your Content With Amazon CloudFront
by alecco on Tuesday November 18, 2008 @12:56PM
(#368472)
We are talking about a cloud service and the same company's CDN system. They already would have said certificates running possibly in multiple hosts. How do you get to "bordering on fraud" from there?
FAIL (Because of your reply tone, please try to be more civilized next time, shame on your up-voters too.)
Re:Distribute Your Content With Amazon CloudFront
by briansmith on Tuesday November 18, 2008 @03:09PM
(#368643)
If I give my certificate that says "this is Brian Smith" to Amazon, and then Amazon uses it to claim to be me, then that is very misleading. It is very similar to me giving my driver's license to my underage brother so he can buy me beer.
If CloudShare used its own "this is Amazon.com's Cloudshare Service" certificate then it might be okay, except (1) they would be using it to sign content that they haven't verified the authenticity of, which is misleading (like notarizing something without any authentication), and (2) you almost always need to mix those static assets with dynamic assets or HTML forms and that all has to happen on the same domain--the domain that receives the POST requests, not the CDN's domain--in order for things to work reliably.
As for tone: the tone with which I wrote my reply is apparently not the same as the tone with which you read it.
Re:Distribute Your Content With Amazon CloudFront
by alecco on Tuesday November 18, 2008 @07:41AM
(#368177)
Well, one of the most common problems are the images at the basket step(s) on SSL with usually low cache hit [ratio]. Servers end up doing routing for static content and backend content, adding complication to the architecture and for content editors. If you can place the images on SSL on the CDN it is much easier and you need less content servers.
The details vary significantly on each scenario. But as a global service I think Amazon will eventually have to add SSL, IMHO.
Re:Distribute Your Content With Amazon CloudFront
by EastSmith on Tuesday November 18, 2008 @03:39AM
(#368045)
Just read the docs, it seems that when you put a file in the CDN they distribute it on all edge servers and you paid for that (which is normal). But it would be great if you can chose on which servers you want the files distributed to. For example I might need the servers just from the european region.
If you have couple of files in the CDN it will not make sense, because the cost to distribute the files around will be marginal, but if you have many GB of data, distributing them to all unneeded servers might be not cost efficient.
Re:Distribute Your Content With Amazon CloudFront
by wensing on Tuesday November 18, 2008 @11:11PM
(#369116)
Can't wait to start using this for Stormpulse. Our traffic is extremely geo-specific (usually Texas and/or Florida), so this is going to help.
To be frank, I haven't been completely satisfied with S3, so maybe this will help insulate us from those outages as well, assuming the content is already cached at the edge.
Re:Distribute Your Content With Amazon CloudFront
by mdasen on Tuesday November 18, 2008 @08:29AM
(#368202)
Has anyone noticed that the transfer charges for the United States are actually less than the charges for S3 once you get over 10TB? Other than the added cost of distributing the files to the CDN, wouldn't that make the CDN as cheap or cheaper than S3? Great place to put your most accessed files.
Re:Distribute Your Content With Amazon CloudFront
by Tichy on Tuesday November 18, 2008 @06:54AM
(#368150)
OK, dumb question, but I thought there was this thing called Apache HTTPD that was traditionally used for serving static content? What ever happened to that? Granted, it has one basic flaw, in that it doesn't deliver usage statistics of my site to Amazon, but other than that?
Re:Distribute Your Content With Amazon CloudFront
by rmaccloy on Tuesday November 18, 2008 @07:04AM
(#368155)
Serving static content from Apache or lighttpd is trivial.
Putting multiple boxes hosting that httpd in various geolocations, setting up DNS and BGP to route users optimally, designing failover routes and keeping N nodes in sync is the hard part.
[1] http://2008.s3.amazonaws.com/09/javascript.mp4
[2] http://d11tgpuxrsgxu4.cloudfront.net/09/javascript.mp4
[1] 6m 56s
[2] 11m 22s
CloudFront: 8m 37s, 8m 12s, 8m 17s
Cost comparisons run very close using their cost calculators for just CloudFiles vs S3...
In addition to ReST, PHP, Python, Java, and C# API's, there is also a web-interface that makes it easy to sign-up, upload content, and CDN-enable it.
In Apache I just enable mod_deflate or mod_gzip, or serve up a .gz and set the Content-Encoding to gzip.
Do CDNs offer this somehow?
Can I set arbitrary headers like Content-Encoding?
Also, does anyone have stats on which browsers support deflate and gzip encodings? I imagine the vast majority at this point do.
I'm not sure yet whether you can do that with CloudFront.
Something I couldn't find is support for SSL. That's key for CDN services.
I would definitely like to use a CDN with SSL sites. I am happy for the domain to be amazon's (or cloudfront, whatever) signed with their cert, I just don't want the browser security to be broken by having non-SSL content on the page.
Is there something wrong with this?
FAIL (Because of your reply tone, please try to be more civilized next time, shame on your up-voters too.)
If CloudShare used its own "this is Amazon.com's Cloudshare Service" certificate then it might be okay, except (1) they would be using it to sign content that they haven't verified the authenticity of, which is misleading (like notarizing something without any authentication), and (2) you almost always need to mix those static assets with dynamic assets or HTML forms and that all has to happen on the same domain--the domain that receives the POST requests, not the CDN's domain--in order for things to work reliably.
As for tone: the tone with which I wrote my reply is apparently not the same as the tone with which you read it.
Not everyone is interested in making sure your feelings don't get hurt on the internet. The sooner you realize that, the better off you'll be.
FWIW, I always found dealing with Akamai and HTTPS a bear.
The details vary significantly on each scenario. But as a global service I think Amazon will eventually have to add SSL, IMHO.
If you have couple of files in the CDN it will not make sense, because the cost to distribute the files around will be marginal, but if you have many GB of data, distributing them to all unneeded servers might be not cost efficient.
To be frank, I haven't been completely satisfied with S3, so maybe this will help insulate us from those outages as well, assuming the content is already cached at the edge.
Putting multiple boxes hosting that httpd in various geolocations, setting up DNS and BGP to route users optimally, designing failover routes and keeping N nodes in sync is the hard part.