Nginx and Memcached, an easy 400% boost in req/s
igvita.com
igvita.com
If you have almost 1000 reqs/sec initially, that's 1ms per request. By bringing this down by the amazing 400% (!!) percent you've shaved off 3/4th of a milisecond per request. Congratulations - you have no idea what you've been measuring. Just the way in which the request is logged can make a 5ms difference. Insignificant and completely uninteresting.
Back when 3d game programming was cool, people would get a rotating cube and show off their 1200 fps frame rate. Of course they would get upset that by adding a texture to the cube the framerate dropped by 400 frames to 800 fps. "Textures are slow!", they'd say. Yeah, right...
Having said that, I agree -- there is a lot of other variables out there, and they should not be swept under the rug.
The kid doesn't realize that if texturing a cube brings a framerate down from 1200 to 800 fps, is as significant as going down from 62 fps down to 60. Even though that is only a 2 fps difference.
A 400% performance gain is a constant performance improvement. I don't think a system like nginx + memcached have linear performance benefits in the first place.
I suspect that memcached was born as a result of sloppy SQL querying multiplied by inefficient SQL schema and lack of RDBMS tuning skills. Moreover, anyone can have memcached with zero programming by either hosting DB on a RAM disk with replication, or using in-memory tables.
(e.g. MySQL query cache is flushed if a single write happens to the table, so all your users will be dumped out of that cache whenever any row is updated.)
Hence you get a better hit-rate with memcached. Perhaps it is also simply easier to tune memcached than most db memory caches.
I benched "retrieve data and instantiate object" on a couple of different, unloaded, systems and a simple select-and-instantiate-from-mysql was a bit faster than the memcached equivalent. I didn't measure CPU usage server-side though, so under load things might be different.
What I am saying is that I suspect that memcached is way overused by people who don't know much about SQL. I am not posing like a DB snob, in fact my skills are fairly modest, but even I know that query caching is just one of the many caches SQL servers employ, and well designed servers easily service thousand+ of requests per second. And that's just one instnace.
Very very very few web sites ever reach such loads. In theory memcached should be more like a very niche product for such rare sites, yet it appears that everybody is using it.
I am against it because it increases the complexity. Memcached deployment and cache control become two more things to get right.
That's all.
The bottom line was that yes, DBs should cache things - but they don't. The main issue was as someone else mentioned, the query cache is flushed whenever the table's written to, which makes it essentially useless on a multi-user website.
Also, memcached distributes the cache itself across multiple machines, which makes a huge difference to cache hit rates. When you have a local query or app cache in a multi-server setup, you end up with each cache storing the same data, so the size of the cache is limited by the amount of RAM you have in the machine. If you distribute the whole cache, you're limited by the amount of RAM in all machines, which means almost every request can hit the cache. Hence you have architectures like FaceBook's 3 TB memcached setup.