Sloppy thinking. Sloppy measurements.

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...

Many dynamic sites can't just cache entire pages and bypass the appserver completely. It would require a lot of changes to the application code.

I refuse to believe in memcached. Apache, along with other web servers, has a built-in in-memory cache for static content. Decent SQL-servers have several caches on different levels, in fact those caches in theory should be far more effective than a simple remote hashtable that memcached is. And all that - on top of OS level disk I/O caching.

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.

I'm going to blog it in detail soon, but I thought I'd mention that tipjoy's front page is entirely static. The content is refreshed very often, and a new file is saved. Right now lighttpd is setup to serve the static page when / is requested. Soon, it will be nginx because of the ease of using it as a load balancer.

It's amazing to me that caching still isn't on by default in Web servers.