I have just started using Drupal but have seen issues where the existing database cache is a bottleneck. My menu has 5,000 items and the overhead to build it, serialize,cache in the db,unserialize was very high making it unuseable. The serialized menu was approx 1.9M according to the DB The workaround was to prevent the builtin caching and store the $_menu in APC user cache.
On 17 Jul 2006, at 01:51, Moshe Weitzman wrote:
There was interest in having it and then it seems the feeling was it's complex. the Caching API allows modules to implement a cache. However, the real benefit of file based caching is 1) Use lightweight webservers threads to serve files 2) Don't need to bootstrap Drupal 3) Don't need an expensive MySQL thread. Keep asking for it and it's more likely to get in since the code is available to be patched against head.
the consensus was that we would make core flexible enough such that this functionality can grow in Contrib for a while. At this point, I think effort is best expended in changing this code from a patch and into a Contrib cache.inc.
Plus, the file caching didn't yield a significant performance improvement (at least not on my setup) unless the "fast path" option was enabled. The "fast path" option makes for a more lightweight bootstrap process. It has been committed to CVS HEAD, but is now called "early page cache" (grep for DRUPAL_BOOTSTRAP_EARLY_PAGE_CACHE). The thing with the "fast path" or the "earl page cache" is that it is not specific to file caching. You probably get the same benefit using a database cache.
Admittedly, file caching could be very useful in the scenario where the database is a significant bottleneck. I could not reproduce such scenario but I'm confident such configuration exists.
-- Dries Buytaert :: http://www.buytaert.net/