3 ms·
http://blog.tr.im/post/159369789/tr-im-r-i-p http://blog.tr.im/post/159369789/tr-im-r-i-p > this required significant development investment and server expansi
by jbellis 17y ago
http://blog.tr.im/post/159369789/tr-im-r-i-p http://blog.tr.im/post/159369789/tr-im-r-i-p
> this required significant development investment and server expansion to accommodate. tr.im has thousands and thousands of users, creating tens of thousands of URLs per day
10K urls per day x 1000 hits for statistics = 10M hits per day, each of which is a read (duh) but also a write to keep a hit count. That's 120 reads + 120 writes per second.
Most of the distributed nosql options can easily handle that on a single node, and the non-distributed ones generally have even higher one-node throughput.
Not to be an armchair architect, but url mapping is pretty simple. Sounds like they were using a bad tool for the job if they were having to throw hardware at it.
- iheartmemcache 17y agoAn avg of 240 dbIO/s is entirely different from peak time IO/s. When someone like Jeff Atwood posts a link using their service, they could easily see 10x the volume. Volume might be really stagnant for 45 minutes, then bam, 10 percent of their req's for the hour come in within a 2-3 minute span. Judging by their blog-post, I'm assuming they needed to have the infrastructure to handle that kinda load. Either way, I modded you up for a pretty thorough analysis (and because I largely agree with you (it basically is a mapped 301 Location: http://newsite/) http://newsite/)). From my armchair standpoint(1), a 256 mb slice + Redis + nginx should be able to handle 10x the volume easy. (1) Well not quite armchair, a good 30 percent of my firm's business is directly related to scaling.
- mahmud 17y agoWell not quite armchair, a good 30 percent of my firm's business is directly related to scaling. Your user name didn't hint at that at all.