I was thinking that this approach is great. However, I think that you should write a wrapper around the memcache functions and that wrapper would make this module more extensible. The reason is essentially because APC also provides a memory-based caching mechanism which is actually faster than using memcached in certain instances.

http://ca.php.net/apc#apc.constants
http://ca.php.net/manual/en/function.apc-store.php
http://ca.php.net/manual/en/function.apc-fetch.php

You can then have a configure option that allows you to choose memcache or apc to cache things in memory.

Comments

robertdouglass’s picture

robertdouglass commented

Yeah, that's on my radar. I'm actually thinking that everything should go through cache.inc, so that you have the option of caching them in the database, memcache or APC depending on what your configuration would best support.

robertdouglass’s picture

robertdouglass commented
Version: » 5.x-1.x-dev
Status: Active » Postponed

Postponing. I need a compelling reason why one would mix APC caching (not opcode... but object) and memcache. It seems like an either-or proposition. The correct place to work on APC caching would be Steve Rude's APC caching module. http://drupal.org/project/apc

sami_k’s picture

sami_k commented

The only reason I was suggesting you put a wrapper around it was because apc is faster than memcached. It's one or the other but often you have the option of both and APC can only be local while memcached can be both local and remote. To me both of them solve the exact same problem so it should just be one module with a wrapper around the cache get/set functions that would abstract the rest of the logic and would reduce the total size of the functionality. Further, you could even combine them to allow the use of apc for certain aspects and memcached for other aspects -- however core code for such perhaps may not be there yet?. Currently with two modules you and slantview are duplicating certain parts of each other's code and due to lack of motivation, it doesn't seem like the apc module is not ready for production. Those are my thoughts on it anyhow, I do respect your decision whichever way you choose.

robertdouglass’s picture

robertdouglass commented

I can see vague fringe cases where one would want to mix and match caching implementations. What is needed is a cache router that maps cache tables to cache implementations. In this case a wrapper would be needed, but it would be needed by core's cache.inc as well.

For the sites slantview and I are building, we basically decide to use either APC object cache or Memcache, and this decision is based on the number of machines on the network. If there is more than one webserver, memcache is what gets used. The problems with redundant caches preclude using APC on a system where there is more than one webserver, and memcache is rarely used on single machine networks. Thus, while I see a theoretical case for using both, I don't see practical cases, and the extra level of abstraction needed to map and route some requests to one cache api and other requests to a different cache api would add complexity and points of failure to the code. It would make it harder to configure and harder to maintain.

slantview’s picture

slantview commented
Status: Postponed » Closed (fixed)

Look for a Cache API change to Drupal core in 7. I am working on it. This will involve some major overhauls to using these modules.