Caching architecture weaknesses

I was reviewing the Drupal caching code and it looks as though drupal will never really be able to scale under serious load. While it is capable of caching data to a database and returning that to a user, that still requires an apache process to fork off and start the php interpreter. Even with a php opcode cache, a person can't get the kind of performance available through static object caching such as available through Squid.

Some of the claims of scalability listed on this site list being able to push 60-100 hits per minute with Drupal. I need 300 hits/second on frequently accessed static objects in order to be able to consider Drupal as a platform, and that's not a hard number to obtain. With a couple of initial tests, I was able to get 38 hits/second out of drupal with the caching enabled.

My proposal would be to add a cache manager to interoperate with Squid allowing an administrator to set headers that would allow certain objects to be cached through a squid cache.

The current code does something like:

if(cache) { /*done*/ }
else {
      header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
      header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
      header("Cache-Control: no-store, no-cache, must-revalidate");
      header("Cache-Control: post-check=0, pre-check=0", false);
      header("Pragma: no-cache");
}

/* finish processing */

A better solution to integrate with squid would be to add another condition after the cache hit detection.

if($cache = page_get_cache()) {
     //same as existing
     exit();
}
else if(variable_get('squid_cache') && $seconds = page_squid_cache()) {
     header("Expires: <some number of seconds in the future specified by cache>");
     //other headers necessary to enable caching
     //note: no exit() call, fall through and process the page
     //other things to do here include possibly tracking a cache miss from squid for statistics
}
else {
      header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
      header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
      header("Cache-Control: no-store, no-cache, must-revalidate");
      header("Cache-Control: post-check=0, pre-check=0", false);
      header("Pragma: no-cache");
}

In the above code, the page_squid_cache() code would check to see if the request URI was entered into a table of cacheable pages, tunable by an administrator. So if there was heavy load anticipated on http://www.example.com/node/13536, "node/13536" could be associated in the squid cache manager, causing the object to be cached in the squid cache and boosting performance on that single object to ~2000 req/sec on modest hardware.

This solution doesn't change any aspect of drupal and doesn't cause a performance hit on the existing cache architecture. If for whatever reason the there is a cache miss on the squid cache and not on the drupal cache, the cached object (with cacheable headers) will be returned to the client.

Thoughts?