Authcache Authenticated Sessions configuration question

Time to first byte after connect has been very poor, and I've been trying to eliminate trips to the database where possible before optimizing the database backend response times.

Thanks for the link, it was very helpful.

After looking at the boot order, the order of $confs that I have is cache_inc, cache_inc_via_authcache (so that cacherouter gets set as handler), cacherouter, memcache_options, memcache_key_prefix, memcache_servers, memcache_bins, and then session_inc.

Memcache module requires 3 servers, and I see the sessions and users bin getting hits, but not the default bin, where there has been no writes or reads, which is as it should be. Question now is, which module sets the session handler to memcache?

Does it go like authcache > cacherouter > memcache for sessions, or is it one of the other two modules, then which folder? Is there a way to ensure that caching for sessions is working as intended, and that there's no duplicate caching...?

Thanks so much! =)

Thanks for the tip. Rerouting the cache flow is a consideration: http://drupal.org/node/230101

Cacherouter has the retrieve from fast_cache option which is a good idea. Thanks! I'll play around with this.

Authcache README.txt states this as example:
$conf['cacherouter'] = array(
'default' => array(
'engine' => 'apc', // apc, memcache, db, file, eacc or xcache
'server' => array(), // memcached (host:port, e..g, 'localhost:11211')
'shared' => TRUE, // memcached shared single process
'prefix' => '', // cache key prefix (for multiple sites)
'path' => 'files/filecache', // file engine cache location
'static' => FALSE, // static array cache (advanced)
),
);
...while regular cacherouter allows an extra variable for fast_cache:

'default' => array('engine' => 'apc',
'servers' => array(),
'shared' => TRUE,
'prefix' => '',
'path' => 'files/filecache',
'fast_cache' => FALSE,
'static' => FALSE),

If Authcache overrides, does it disregard only specific bins, or will it not honor any settings meant for cacherouter?

Also, I'm wondering if the variable for this settings is deprecated Jonah:
$conf['page_cache_fastpath'] = 1;

Thanks for the additional info on #9. Api info on page_cache_fastpath states that it only handles the 'cache_page' table ("bin"): http://api.drupal.org/api/drupal/developer--hooks--core.php/function/pag...

..which I believe is the only bin you are working on from the link that you gave me, but this link here: http://groups.drupal.org/node/18177 [Subject - here you go." by Steve] ...shows that multiple bins can be used, and obviously multiple engines as well after reading the issue queue. He has fast_cache variable set to TRUE for default (placeholder for cache) and cache_page to load up at DRUPAL_BOOTSTRAP_EARLY_PAGE_CACHE, while the others are not absolutely required before hitting the database.

The line 47 of authcache.inc suggests that data under additional bins when using cacherouter never get stored into memory depending on the settings.php statement order. The better way to implement this module is to be a downstream module, sort of like ubuntu is to debian, since caching technologies come and go, and the use of a caching strategy based on roles would depend on the hardware and lower level technologies as well. Can you elaborate on the roadmap?

You're limiting the use of authcache and memcache's purpose of storing items in memory/other caches by implementing only one bin. The routing logic of your module only handles default thus breaking cacherouter functionality without documentation. Loading items into memory at DRUPAL_BOOTSTRAP_EARLY_PAGE_CACHE when calling cache.inc does not absolutely require the use of page_fast_cache, and this structure gives flexibility in the order of the bootstrap access of memory by functions. That is one concern.

The second concern is that, according to your documentation, cacherouter or memcache needs to be enabled first, then as stated, earlier your routing logic does not call other bins, leading to performance degradation and admins wondering why.

I didn't ask whether your module was a caching engine. I wanted the other modules to behave as intended when configuring the cacherouter bins. Because cache_inc is overridden by authcache, you essentially take over the caching engine layer. Calling other bins for memory avoids trips to the database during subsequent function calls. http://api.drupal.org/api/drupal/includes--cache.inc/function/cache_get/6

I'm sure there's numerous other uses as well which requires hacks: http://drupal.org/node/797610

Unless someone issues a patch, this is better marked as won't fix.

Hey, sorry about last time. No hard feelings.