3 ms·

Indeed I am, that's what I get for envelope math. I think there's a price/performance sweet spot where a small server with something like varnish makes a lot o

by awj 14y ago

Indeed I am, that's what I get for envelope math. I think there's a price/performance sweet spot where a small server with something like varnish makes a lot of sense. Move outside of it in terms of hits/day or acceptable cost/hit and S3 gets a lot more attractive, especially when you can slap CloudFront in front of it so easily. Actually, looking at the CloudFront pricing, unless you plan on doing a lot of cache invalidations it comes out much cheaper than S3.

aidos 14y ago
Cloudfront in front of ec2 would be cheaper (you'd potentially pay a lot to have it in front of s3). Also, we discovered the hard way that cloudfront is nowhere near as resilient as s3 under load (and if you need to do a cache invalidation you are pretty much screwed).
- awj 14y ago
  Can you expand on the resiliency of cloudfront? We've had great success after switching to it for hosting of map tiles, but possibly haven't pushed it hard enough yet. (I pushed it hard, but defining "enough" is very, very tricky) Cloudfront in front of S3 isn't particularly expensive. Invalidations aside they're billed the same way and you're paying less per bit|request. Invalidations, however, are a bitch. We've had a couple of times that we put up a map, found a problem with it, then decided to wait out the CF cache rather than pay for a bajillion invalidations.
  - aidos 14y ago
    I have to be honest, I can't remember how much load we tried putting on cloudfront during our testing. We may have just assumed that as cf is a regular cdn and s3 is a big one of a kind data store, s3 was going to be more resilient. We did load test s3 and it scaled linearly (with some caveats). For our use case (a single huge burst of requests) we were willing to drop all caching and pay the additional money. It was absolutely worth it (and under non-sustained load it didn't cost much). We actually used s3 as a sort of cache in front of realtime data. So the client js was accessing objects on s3 that were being refreshed every second. It worked incredibly well where other things (like gae, who disabled our account under load) had failed us in the past.
  - deleted 14y ago
    [deleted]

by awj 14y ago

aidos 14y ago

Cloudfront in front of ec2 would be cheaper (you'd potentially pay a lot to have it in front of s3). Also, we discovered the hard way that cloudfront is nowhere near as resilient as s3 under load (and if you need to do a cache invalidation you are pretty much screwed).

awj 14y ago
Can you expand on the resiliency of cloudfront? We've had great success after switching to it for hosting of map tiles, but possibly haven't pushed it hard enough yet. (I pushed it hard, but defining "enough" is very, very tricky) Cloudfront in front of S3 isn't particularly expensive. Invalidations aside they're billed the same way and you're paying less per bit|request. Invalidations, however, are a bitch. We've had a couple of times that we put up a map, found a problem with it, then decided to wait out the CF cache rather than pay for a bajillion invalidations.
- aidos 14y ago
  I have to be honest, I can't remember how much load we tried putting on cloudfront during our testing. We may have just assumed that as cf is a regular cdn and s3 is a big one of a kind data store, s3 was going to be more resilient. We did load test s3 and it scaled linearly (with some caveats). For our use case (a single huge burst of requests) we were willing to drop all caching and pay the additional money. It was absolutely worth it (and under non-sustained load it didn't cost much). We actually used s3 as a sort of cache in front of realtime data. So the client js was accessing objects on s3 that were being refreshed every second. It worked incredibly well where other things (like gae, who disabled our account under load) had failed us in the past.
- deleted 14y ago
  [deleted]