3 ms·
AWS is nowhere near as reliable as a compiler. We've seen things ranging from "S3 intermittently takes 60 or 120 seconds (or some multiple thereof)" (but appare
by deathanatos 9y ago
AWS is nowhere near as reliable as a compiler. We've seen things ranging from "S3 intermittently takes 60 or 120 seconds (or some multiple thereof)" (but apparently only for my buckets…) to spatial indexes in Aurora just flat out didn't work when they were released, to S3 acknowledges writes prior to them being available to be read (causing a reader who picks up the item to receive a 404), to ELBs corrupting the HTTP connection depending on packet timings.
That's aside from the more common issues of "this VM is just going to bite the dust", which is something I feel is just inevitable.
The kernel is more reliable, IMO (except when it comes to the Thinkpad TrackPoint drivers).
- openasocket 9y ago> S3 acknowledges writes prior to them being available to be read (causing a reader who picks up the item to receive a 404) That's exactly documented behavior: http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction....
- amichal 9y agoAnd very visible in practice. In one case we had a bucket with about 50,000 documents posted to s3 the with 204 created replies. A separate process runs to verify the uploads has 10 or so outliers taking 30s or longer to for a GET to see them. One took 10 tries spaced 30s apart (so 5 minutes) to show up. The next 50k the biggest outlier was only 5s.
- deathanatos 9y agoHuh. TIL. I swear we searched the docs when we ran into that, and found the same consistency guarantee minus that rather large caveat, but Wayback says that was there at the time. Perhaps we were looking at a different page, but it does appear this is and was documented behavior. That's a hugely unuseful caveat in practice though. I'd really love to have consistent reads.