It is great to see articles that include code snippets and architecture diagrams. People should use direct example more often instead of trying to describe things in words.
Lastly, I'd suggest using nginx (http://wiki.codemongers.com/Main) as I found it to be a serious improvement on lighttp for many of my projects.
if ($http_cookie ~* "auth=1" ) { proxy_pass http://backend ; break ; }
if (!-f $request_filename) { proxy_pass http://backend ; break ; }
Except that it's not. One of the reason the classic web servers are so amazingly fast with static files is that they, along with the operating systems they run on, have spend significant time trying to optimize this process. For linux, for example, look at the sendfile(2) system call, or the TCP_CORK socket option. These were expressly designed to permit a userspace program to get a file through the kernel and onto the wire with as few CPU cycles and memory copies as possible.
One of the most frustrating things about the Web 2.0 crowd (from the perspective of curmudgeons like me) is that they really don't have a clue about any of this complexity. They just figure that they'll stuff everything into a DJango/Rails/whatever request and scale up later. Then when they run into trouble, they end up turning to tools like Apache as black boxes and designing Rube Goldberg apparatii around them when they really should be looking at the problem more directly.
Really, folks: those low level APIs are your friends. They're not nearly as scary as they look. Even if you end up with an off-the-shelf solution, knowledge of this stuff can only be good for you.
1. Ensure that all your HTTP responses have proper ETags, and make sure you process the If-Match and If-None-Match request headers appropriately to avoid doing unnecessary work.
2. Put a simple caching reverse proxy (e.g. Squid, Varnish, mod_disk_cache) in front of your application. Then, tune the cache-control directives to allow the cache to return cached responses without hitting the back end. For this to work for HTTPS responses, you need to put a HTTP-to-HTTPS proxy in front of the caching proxy.
3. Add a system like the one described in the article, that immediately purges entries from the cache when they are updated in the back-end.
4. Purchase a caching, SSL-enabled, load-balancer appliance (e.g. Big-IP) that is built to do all of the above nearly automatically.
Most people never need to go beyond step #2.
