[development] Object caching

[George Kappel]

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