[drupal-devel] [feature] Improved caching with eAccelerator/turck mmcache

Yrlec drupal-devel at drupal.org
Sat Jun 4 08:07:09 UTC 2005

Issue status update for http://drupal.org/node/24260

 Project:      Drupal
 Version:      4.6.0
 Component:    base system
 Category:     feature requests
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  Yrlec
 Updated by:   Yrlec
 Status:       patch

Dear Dries,

I am bit surprised by your reply. I get the feeling that you do not
want people to contribute. 

- Ok I forgot to changing the camel-casing on one variable, is that
such a big deal?
- I already said that I did not use the HEAD but if you look at the
code you will see that it is quiet easy to implement anyway (just copy
the upper "if" of each function).
- Just because it may not be a major performance boost does that mean
it is a bad thing? IMHO all performance improvments should be
implemented since performance is a major issue for many users.
-What has that got to do with it? Even if you use Squid you will
benefit from caching static content in memory, neither thing has to
exclude the other.

I love Drupal and I thought I could try and give something back by
contributing but I know I realize my help is probably not wanted.


Previous comments:

June 3, 2005 - 19:52 : Yrlec

Attachment: http://drupal.org/files/issues/newcache.php (3.82 KB)

I'm not sure if this is the best place to post, please let me know if I
should post somewhere else.

I've done some changes to bootstrap.inc to make it use the semaphore
cache of either eAccelerator or Turck mmCache instead of the database
to handle the caching. I've not done any benchmarking but I'm quiet
sure that it will speed things up. I'm afraid that I didn't base my
code on the latest version so I apologize if my changes aren't
compatible with the current cvs-version. As you can see, if neither
eAccelerator nor Turck mmCache isn't available on the system the old
caching mechanism will be used.

The changes are in cache_get, cache_set and cache_clear_all. I'm sorry
I didn't post a diff but I think it will be quiet easy to implement


June 3, 2005 - 20:31 : walkah

+1 in principle... however, rather than see this get committed directly,
I'd rather see a "caching framework" evolve...

we've also had other talks about making drupal more squid friendly, in
addition to using memcached, etc.

i'm willing to help put some brainpower into this...


June 4, 2005 - 07:16 : Dries

- The variable names are not consistent with our coding style (no camel

- The code won't work against HEAD.

- This needs to be benchmarked before it can be committed.  I don't
think it will buy us much.

- I agree with James that the squid changes might be worth looking at
too (forgot the URL).

More information about the drupal-devel mailing list