[plugin] [ORPHAN] zem_cache: experiment

A number of people have been asking about a ‘staticize’ clone for Textpattern. I’m not yet convinced that such a thing is necessary, but I’ve thrown together a quick plugin to test the idea. This is not a complete solution – flushing is a bit inconvenient, and there’s still database activity because plugins, config settings etc are loaded from a table.

note – your image directory must be writable. Cached content will be stored in images/cache.

You don’t have to cache the entire page. If you’re using more than one zem_cache tag per page, see the ‘id’ and ‘ctx’ attributes below.

The cache must be flushed manually; it won’t happen automatically when you post or edit an article. To flush the cache, append “?flush_cache=1” to any Textpattern URL. Alternatively, place a <txp:zem_flush /> tag on a seldom-used page, and load that page in your browser to force a flush.

You can check if it’s working by viewing the source of a cached page and scrolling to the bottom. There should be a message that says “fresh copy”, “cached copy” or “cache flushed”.

Supported attributes:

timeout
Specifies the expiry time in seconds. Default is 3600. A small figure like 120 will give you some protection against heavy load, and eliminate the need for manual flushing.

id
Use this if you’re using multiple zem_cache tags per page. Each tag should have a different id. It doesn’t matter what the id is set to – a number is fine – as long as each one is different.

ctx
Use this to cache a single copy of something globally across all pages, rather than once per page. For example, <txp:zem_cache ctx="recent1"><txp:recent_articles /></txp:zem_cache>

Re: [plugin] [ORPHAN] zem_cache: experiment

The previous one prevented comments from working; this one fixes that. It also hooks into the admin side plugin stuff, if you’ve installed the patch, to automatically flush the cache when an article is posted or edited.

My guess is that caching won’t have a dramatic effect on run-times (not nearly as much as removing the dns lookup from the logging code). It might be effective in reducing server load, however, particularly on pages that have long article lists – this could make it worthwhile on sites with heavy traffic.

Re: [plugin] [ORPHAN] zem_cache: experiment

zem, this is a very nice plugin. And you are right on point with:
“It might be effective in reducing server load, however, particularly on pages that have long article lists – this could make it worthwhile on sites with heavy traffic.”

I tested with ab, and only wrapped zem_cache around the article-tag:

of articles

requests per second with zem_cache

requests per second regular

10

7.7 #sec

4.9 #/sec

20

7.5 #sec

3.9 #/sec

(Note: The articles are quite long.)

Especially on long article-lists it saves dozens of [admittedly very short and light] queries. Currently with txp-code there are at least three additional queries made for each item in a list of articles: one for number of comments, one for real-name of author and one for the neighbouring article. For my example with 20 articles, total queries dropped from 75 (without cache) to 9 (with zem_cache wrapped around the article-tag).

Peak-Memory Usage stayed the same, since even after retrieving the cached portions from cache, the content is passed around in functions to be processed as if it might contain further txp-tags.

Note: I had to edit the code of the plugin to correct the path: I used $path_to_site instead $txpcfg[‘root’]. Maybe you can update the plugin at some point, zem?

Re: [plugin] [ORPHAN] zem_cache: experiment

I’m getting an error that looks like this “Warning: unlink(/home/nomo/public_html/ve/cache/1a3b829ae3a79f11ea074fe25307ecdf): No such file or directory in /home/nomo/public_html/ve/textpattern/lib/txplib_misc.php(304) : eval()’d code on line 2031” on individual articles on ve.nomo.us.

It seems to work fine on auto.nomo.us, and even on the front page of ve.nomo.us, but individual articles bomb out. Though, I just thought of something…. turning off sgb_url_handler seems to fix it.

Zem_cache and sgb_url_handler don’t seem to play well together. Which is a shame, because I absolutely love how sgb_url_handler and sgb_error_documents work.