That would have been a good article. It's too bad that the only content here is "IMVU uses memcached and it reduces database load". Not exactly earth shattering. I have no idea why this is getting upvoted.
The article doesn't say anything about the setup, and the 150k/sec is actually a max - their mean is more like 100k/sec.
> if the result of all of those queries is already in memory somewhere, we can send the page back in less than a second, whereas it would take longer than that if we had to go to the database for each query.
This is breaking news? Seriously, fetching data in memory is substantially faster than doing disk IO. It also helps to do the full query in one pass and inside the database, rather than several separate queries that keep dragging data back and forth. You can get a further speed-up by staying small enough to run inside the processor caches - J (http://jsoftware.com/) and K (http://kx.com/) are quite fast, despite being interpreted.
While Redis has somewhat different use cases than Memcached (Redis is an in-memory db, not just a cache), it's another option.
1) For IMVU users who may not be web server gurus, give a peek into what goes into building a large, 24/7 website.
2) For those who already know memcached, provide some data on load capability for comparison and amusement.
This particular memcached is running an ancient version of Debian on a three year old dual-Xeon 1U box, and it is using TCP. (This is different from many users who move to UDP, to get more throughput but more loss)
The main tuning happens in the switches, where we attempt to have sufficient capacity to avoid packet loss except under the absolutely worst load transients.
I'd love to see other similar data from other sites, btw!
I was just today tweaking memcached use on one of my Rails apps and also a customer's app. In addition to using the out of the box support, I used a few simple tricks with ActiveRecord also (I wrote this up at rubyplanet.net).
7 comments
[ 0.34 ms ] story [ 20.0 ms ] thread> if the result of all of those queries is already in memory somewhere, we can send the page back in less than a second, whereas it would take longer than that if we had to go to the database for each query.
This is breaking news? Seriously, fetching data in memory is substantially faster than doing disk IO. It also helps to do the full query in one pass and inside the database, rather than several separate queries that keep dragging data back and forth. You can get a further speed-up by staying small enough to run inside the processor caches - J (http://jsoftware.com/) and K (http://kx.com/) are quite fast, despite being interpreted.
While Redis has somewhat different use cases than Memcached (Redis is an in-memory db, not just a cache), it's another option.
1) For IMVU users who may not be web server gurus, give a peek into what goes into building a large, 24/7 website.
2) For those who already know memcached, provide some data on load capability for comparison and amusement.
This particular memcached is running an ancient version of Debian on a three year old dual-Xeon 1U box, and it is using TCP. (This is different from many users who move to UDP, to get more throughput but more loss)
The main tuning happens in the switches, where we attempt to have sufficient capacity to avoid packet loss except under the absolutely worst load transients.
I'd love to see other similar data from other sites, btw!
As far as I can tell, it sounds like they just stumbled into a working configuration, which I'd like to believe is not the point at all.