4 ms·

I'm in a middle of creating a web application, and my plan was to serve static files from S3. Based on your post, it seems like a really bad idea. If the proble

I'm in a middle of creating a web application, and my plan was to serve static files from S3. Based on your post, it seems like a really bad idea. If the problems are so apparent, I wonder why this is so generally accepted and recommended approach. One example, Heroku guide that praises putting static files on S3: https://devcenter.heroku.com/articles/s3 https://devcenter.heroku.com/articles/s3

aidos 14y ago
As always, test for yourself but I wouldn't hesitate to use S3. I host 1.5 million images on S3 and I've never had issues with 500 errors. I've also done extensive testing of S3 under load and it's simply amazing. Frankly S3 is one of the few bits of infrastructure I DO trust.
- saurik 14y ago
  I trust S3 a lot (in fact, there was a time I had >1% of all objects in S3; I have since deleted a very large percentage, but I believe I still have well over a billion objects stored). I would definitely agree: it doesn't fail under load; for a while I was seriously using S3 as a NoSQL database with a custom row-mapper and query system (not well generalized at all) that I built. However, this particular aspect is a known part of S3 that has been around since the beginning: that it is allowed to fail your request with a 500 error, and that you need to retry. This is something that if you read through the S3 forums you can find people often commenting on, you will find code in every major client library to handle it, and it is explicitly documented by Amazon. "Best Practices for Using Amazon S3", emphasis mine: > 500-series errors indicate that a request didn't succeed, but may be retried. Though infrequent, these errors are to be expected as part of normal interaction with the service and should be explicitly handled with an exponential backoff algorithm (ideally one that utilizes jitter). One such algorithm can be found at... -- http://aws.amazon.com/articles/1904 http://aws.amazon.com/articles/1904 Regardless, the 2% failure rate on that one S3 IP endpoint is definitely a little high, so I filed a support ticket (I pay for the AWS Business support level) with a list of request ids and correlation codes that returned a 500 error during my "static hosting + redirect" test today. I'll respond back here if I hear anything useful from them.
  - aidos 14y ago
    Interesting. I guess in the case of static web hosting you could use onerror to deal with failed frontend requests to smooth out the broken images from the user perspective. Though as I say, not been a problem for me.
    - saurik 14y ago
      Yeah, for images you can probably deal with that; but what if your JavaScript doesn't load because the script itself was a 500 error, or the entire website doesn't load because of a 500 error... well, you're screwed. The use case here is for zone-apex whole-site static website hosting (either of just canonicalizing redirects or of the final webpage: same issue).
      - aidos 14y ago
        I've just discovered that you can use the same technique for script and style tags too (though I'd rather not have to). It sounds like Jeff has tracked down the specific issue in your case, so things are looking up :)
  - recuter 14y ago
    2% failure rates are excessive, agreed - but why is the requirement to retry on 500 so off-putting? Virtually all API's have this occur on some level and you do the exponential backoff song and dance. What am I missing that makes this such a show stopper with browsers? You can still do the backing off clientside with a line or two of javascript. Seems like the pros outweigh the cons but I'm probably missing something.
    - saurik 14y ago
      You are still thinking about this as an API, with for example JavaScript and some AJAX. The use case here is zone apex static website hosting: if you go to http://mycompany.com/ http://mycompany.com/ and get a 500 error, the user is just going to be staring at an error screen... there will be no JavaScript, and the browser will not retry. As I actually explicitly said multiple times: for an API that is a perfectly reasonable thing to have, but for static website hosting it just doesn't fly.
- pestaa 14y ago
  It might be interesting to state in which zone you and GP host those files. My buckets are in Ireland and I haven't seen 5xx problems. I'm not a heavy user, though.

aidos 14y ago

As always, test for yourself but I wouldn't hesitate to use S3. I host 1.5 million images on S3 and I've never had issues with 500 errors. I've also done extensive testing of S3 under load and it's simply amazing. Frankly S3 is one of the few bits of infrastructure I DO trust.

saurik 14y ago
I trust S3 a lot (in fact, there was a time I had >1% of all objects in S3; I have since deleted a very large percentage, but I believe I still have well over a billion objects stored). I would definitely agree: it doesn't fail under load; for a while I was seriously using S3 as a NoSQL database with a custom row-mapper and query system (not well generalized at all) that I built. However, this particular aspect is a known part of S3 that has been around since the beginning: that it is allowed to fail your request with a 500 error, and that you need to retry. This is something that if you read through the S3 forums you can find people often commenting on, you will find code in every major client library to handle it, and it is explicitly documented by Amazon. "Best Practices for Using Amazon S3", emphasis mine: > 500-series errors indicate that a request didn't succeed, but may be retried. Though infrequent, these errors are to be expected as part of normal interaction with the service and should be explicitly handled with an exponential backoff algorithm (ideally one that utilizes jitter). One such algorithm can be found at... -- http://aws.amazon.com/articles/1904 http://aws.amazon.com/articles/1904 Regardless, the 2% failure rate on that one S3 IP endpoint is definitely a little high, so I filed a support ticket (I pay for the AWS Business support level) with a list of request ids and correlation codes that returned a 500 error during my "static hosting + redirect" test today. I'll respond back here if I hear anything useful from them.
- aidos 14y ago
  Interesting. I guess in the case of static web hosting you could use onerror to deal with failed frontend requests to smooth out the broken images from the user perspective. Though as I say, not been a problem for me.
  - saurik 14y ago
    Yeah, for images you can probably deal with that; but what if your JavaScript doesn't load because the script itself was a 500 error, or the entire website doesn't load because of a 500 error... well, you're screwed. The use case here is for zone-apex whole-site static website hosting (either of just canonicalizing redirects or of the final webpage: same issue).
    - aidos 14y ago
      I've just discovered that you can use the same technique for script and style tags too (though I'd rather not have to). It sounds like Jeff has tracked down the specific issue in your case, so things are looking up :)
- recuter 14y ago
  2% failure rates are excessive, agreed - but why is the requirement to retry on 500 so off-putting? Virtually all API's have this occur on some level and you do the exponential backoff song and dance. What am I missing that makes this such a show stopper with browsers? You can still do the backing off clientside with a line or two of javascript. Seems like the pros outweigh the cons but I'm probably missing something.
  - saurik 14y ago
    You are still thinking about this as an API, with for example JavaScript and some AJAX. The use case here is zone apex static website hosting: if you go to http://mycompany.com/ http://mycompany.com/ and get a 500 error, the user is just going to be staring at an error screen... there will be no JavaScript, and the browser will not retry. As I actually explicitly said multiple times: for an API that is a perfectly reasonable thing to have, but for static website hosting it just doesn't fly.
pestaa 14y ago
It might be interesting to state in which zone you and GP host those files. My buckets are in Ireland and I haven't seen 5xx problems. I'm not a heavy user, though.