Makes me go all the more ‘hmmm’ for why S3 was too slow for Zooomr. If it was because migration processes needed to read/write the data a lot then perhaps it would have been best done in a set of EC2 machines.

Maybe that’s where the speed difference was, in EC2 and not in S3 itself.

AFAIK, with EC2 you are sharing the hardware amongst multiple other virtualized systems, which may or may not be yours or somebody else’s etc. Definitely will be slower than dedicated hardware.

In blind “taste tests”, Amazon S3 proved to be as fast to our customers at SmugMug’s own storage.

We use a tiered approach because Amazon’s bandwidth cost isn’t great for a company of our size. We buy bandwidth in 1Gbps chunks, and we get it cheaper than $0.20/GB.

So the more we can serve out of our cheaper bandwidth, the better.

I see from the computerworld article that SmugMug needed to take the tiered approach and cache the hot files on your own internal infrastructure for speed purposes. That just sounds like normal architecting to me . . . something you’ve got real world experience with and Kristopher is slowly coming to grips with himself.

There’s no substitute for experience, no matter how much of a whiz kid you may be. The more experience you have the more you realize you don’t know and generally better able to keep an eye out for gotchas that never came to mind before.

If so, I think I have to blame ‘coder error’ on their slowness problems, since we (SmugMug) are more than 100X Zooomr’s size and haven’t had any performance problems like they were suggesting.

*shrug*

There are plenty of pitfalls for people who don’t realize the gotchas around S3, but properly written to, it can be blazingly fast.