Enable Memcached fallback for non-nginx

[stklcode]

I was wondering about why the print_cache() methods for the memory backends have been left empty instead of doing something useful like .. let's say print the cache... The memcached->get() is called anyway a couple of lines earlier, but the result is just ignored. Can't imagine any reason for that. (shouldn't be queried if not used).

I ran a couple of tests on a real-world site, enabled memcached without the nginx config and added a few lines to the backend. Processing time dropped from ~180ms to ~60ms using Memcached through PHP (~65ms for DB cache), so I think it's worth enabling this for users not able to reconfigure their server or not using nginx at all.

Of course the server module performs far better than taking the loop through PHP and this should be the preferred way. The setup information can still be displayed if using nginx with a note on performance.

Makes debugging a little harder, so maybe one could add a hint in the HTML comment (if detailed signature is enabled) to point out which path is actually used.

I started working on this in my fork to ge a smooth solution. So if we decide to add this in future releases (not in 2.3.0 I believe), it should be about ready for testing.

Open for discussion.

[chesio]

Just one note to your benchmarks (I assume you are running them with code from master branch). I made a similar benchmarks for HDD cache before I submitted #98 and there's been little improvement until #93 has been merged. In other words, current stable version of Cachify does not benefit from these fallbacks that much, because cache is printed in template_redirect hook that is run just before theme template file is loaded. That's perhaps why the respective methods have been left empty.

I'm mentioning it, cause I realized that printing cache early (ie. change introduced in #93) is not backwards compatible in some scenarios (see #138), so I guess we should decide first, whether we keep it like it is, try to minimize possible back-compat issues in some way or revert the change completely.

Makes debugging a little harder, so maybe one could add a hint in the HTML comment (if detailed signature is enabled) to point out which path is actually used.

This is quite important I'd say. I haven't done it for HDD cache yet, cause there's no straightforward solution.

[stklcode]

Absolutely right, thanks for the reminder.

Of course my tests are based on the development state (not on a production site, but a staging version), I'm not going to optimize legacy code.

This is quite important I'd say. I haven't done it for HDD cache yet, cause there's no straightforward solution.

Actually there is one now. With the $sig_detail parameter passed to the print_cache() method (introduced in #108), the information, if a user want's to see additional details in the HTML comment (e.g. number of DB queries for DB cache) is present. This activated, the fallback prints can just add a single line to the cached content, just before exit;.
We should decide (uniform for every method), if and what should be printed there. No internal data, maybe just the current time...

[chesio]

This activated, the fallback prints can just add a single line to the cached content, just before exit;

You mean adding an extra comment after closing html tag? Something like:

</html>
<!-- Cachify: cache file served via PHP -->

This could work :)