Not really working although everything seems to be in place. By not really working I mean the cache's are not in general populating (am mirroring the db tables). Seemed to work a little better with the db include but that also generated a mysql insert error. My goal is to see that if I set up caching then repeatedly visit a page, it gets a decent hit rate. The maximum the statistics module has so far reported is ~4% and that on default, so something is wrong. Trying the other module (cache router).

Comments

jvandyk’s picture

Be sure your minimum cache lifetime setting is other than None to avoid frequent cache clears.

kyberuserid’s picture

Doesn't appear to affect it. Have verified that the cache router works. Currently am disabling this module except to get the statistics (since the other module's GUI isn't operational in 6.x yet). This works well and when the other module's set up is in effect can then disable it and run this one to see that the cache is being used in the way I expected (30%-90% hit rate) when (and only when) it (cache router) is enabled.

kyberuserid’s picture

Perhaps you meant something other than the dropdown in the Performance admin panel. In any case confirmed by that by the procedure outlined above it has no effect. It's not that cache(s) are being cleared, they're not being used. Below shows the setup, with this module enabled. Update: changed below to show what needed to allow both to be enabled at the same time getting the working caching and the stats.

  $conf = array(
   // The path to wherever memcache.inc is. The easiest is to simply point it
   // to the copy in your module's directory.
   //'cache_inc' => './sites/all/modules/memcache/memcache.inc',
   //'cache_inc' => './sites/all/modules/memcache/memcache-session.inc',
   //   or
   // 'cache_inc' => './sites/all/modules/memcache/memcache.db.inc',
   	                      'memcache_servers' => array(
	      'localhost:11211' => 'default',
	      'localhost:11212' => 'page',
	      'localhost:11213' => 'content',
	      'localhost:11214' => 'sessions',
	      'localhost:11215' => 'users',
	      'localhost:11216' => 'menu'
	             ),
	    'memcache_bins' => array(
    'cache' => 'default',
    'cache_menu'   => 'menu',
    'cache_page'   => 'page',
    'cache_content' => 'content',
    'cache_sessions' => 'sessions',
    'cache_users' => 'users'
    ),
	'cache_inc' => './sites/all/modules/cacherouter/cacherouter.inc',
        'cacherouter' => array(
         'default' => array(
           'engine' => 'memcache',
           'server' => array('localhost:11211', 'localhost:11212', 'localhost:11213', 'localhost:11214', 'localhost:11215', 'localhost:11216' ),
           'shared' => TRUE,
           'prefix' => '',
           //'fast_cache' => TRUE,
        )),
 ); 
jeremy’s picture

Status: Active » Postponed (maintainer needs more info)

If you're using cache router, then this issue should be moved to the cache router issue queue. If you're using memcache, then please answer the questions below:

If you enable the admin module, are you seeing a lot of misses without sets? Are all your memcache instances running?

kyberuserid’s picture

Status: Closed (fixed) » Postponed (maintainer needs more info)

I am using memcache (and cache router). As noted, the use of this drupal module (for stats display only) is also accomplished by the configuration above (which ATM I am using for more fine grained caching but the module sharing is the same). The stats from the memcache api module show that caches are being used (in some cases with close to 100% hit rate). I will be verifying further but also am not getting the impact desired from caching so will want to look at addressing that as part of a solution to some other issues in my d6 projects. I am leaving this a bug report since SFAIK, without cacherouter or something else, the given procedures don't result in what the setup above shows, i.e. if I let memcache api be included instead of cache router, the memcache displays show that the caches are not being used. I'm more interested in the larger solutions mentioned though so others can give feedback on uncommenting the include commented out above. However I'm closing it; someone willing to track it can reopen/open their own.

kyberuserid’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

Status: Postponed (maintainer needs more info) » Closed (fixed)