You are not logged in.
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.
It’s a little rough, and probably has some bugs.
If you try it out, please post before and after runtimes to this thread.
To use it, surround a page with the txp:zem_cache tag, like this:
<txp:zem_cache><!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=“http://www.w3.org/1999/xhtml” xml:lang=“en” lang=“en”>
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”.
<txp:zem_cache ctx="recent1"><txp:recent_articles /></txp:zem_cache>
Last edited by wet (2009-05-28 11:50:54)
BTW: I get runtime figures around 0.017-0.018 with my front page cached, and 0.035-0.04 without.
Hardly earth shattering, but it’s an improvement.
Incidentally, Staticize 2.5 doesn’t bother caching content if the runtime is less than 0.05.
Last edited by zem (2004-08-07 10:09:50)
Wow. Since I’m on TextDrive (runtime of 0.11), I don’t think I need this one, but I’m going to nominate you as TXP Plug-In Developer of the Year.
Once I figure out where to do that…
TextPattern user since 04/04/04
Before: 0.0685, 0.0577, 0.1410 Avg: 0.0890
After: 0.0564, 0.0315, 0.0446 Avg: 0.0441
Maybe not a huge improvement but I think it will payoff in the long run.
I’ve uploaded a new version:
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.
DUH! Disregard the post below. I need to redo my testing because I’m stupid.
<strike>I installed this plugin. There seems to be no difference in runtimes. I tested 4 separate pages, recording 10 samples per page. The numbers below represent the average of each page:</strike>
<strike>Before: 0.1450, 0.1124, 0.1270, 0.0879</strike>
<strike>After: 0.1475, 0.1011, 0.1245, 0.1086</strike>
<strike>I’m using 1.0rc3</strike>
Last edited by vaughn-taylor (2005-04-13 14:45:23)
Work until your carpal tunnel makes you cry.
My “bloggy” TP site >> liberalrevolt.com
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:
||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?
Last edited by Sencer (2005-04-29 14:13:52)
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.
Try http://thresholdstate.com/download/zem_cache-0.4.txt. Should work with RC3, and might be a little faster than the older one with PHP 4.3 and higher.
That seems to play perfectly nicely with my other plugins. Thanks.