Caching the Drupal bootstrap I'm curious if anyone has made attempts to "cache" the bootstrap process in Drupal.

Normally, Drupal will run the 7 bootstrap phases on each request, but perhaps on a deployed production system, one could "do away" with some or all of these?

Possible suggestions I have in mind could be


Serializing the bootstrapped state and sticking it into memcache
A script could generate a patch for bootstrap.inc that will hardcode certain information into the file.
I believe David Strauss has tried to keep a bootstrapped Drupal running on libevent.
Other craziness?


What attempts are there, and which are known to be (somewhat) reliable?
PHP is a shared nothing architecture. That has its advantages and disadvantages.

One disadvantage is that it's not easy to do something like this. There isn't much of a state that can be stored somewhere.

I did some quick tests and when logged in, then the boostrap seems to take about ~17% of the total time and more than 50% of that is actually loading all the .module and .inc files. That's not something that you can store in memcache. Also, it doesn't seem to matter much if I use memcache or the database cache.

I tried to get some results when having the page cache enabled, but Xhprof doesn't seem to return reliable results then; the whole thing simply seems to be too fast. But even then, the biggest part involves executing init/exit hooks and loading files it seems. I found an interesting issue there: It looks like the User module is seriously slowing down the cached page response because it triggers the registry due to the entity controller in the .module file.

That said, David Strauss showed some experimental work in Copenhagen where he created a memory snapshot after bootstrapping and then returning to that once the page was served. He did use Drupal 6 for that. After looking at the numbers above, I imagine that the performance gains of doing this in Drupal 7 would be quite a bit smaller. One reason for this is that the database connection is lazy loaded (And you can get quite far in the bootstrap when using e.g. Memcache before you need to execute the first query) and there's a lot that is cached. 

What's really bad in Drupal 7 is the render layer with these huge arrays and endless recursions and loops. That one pretty much undoes all the performance work that went into Drupal 7. Let's see how it looks in Drupal 8, if Twig makes it into core.

Lastly, about the mentioned advantages. One large advantage is that memory leeks are rather irrelevant because everything is freed after each request. I've seen many Java applications where memory usage constantly increases and need regular restarts.