Textpattern CMS support forum

You are not logged in. Register | Login | Help

#31 2015-05-12 08:31:47

etc
Developer
Registered: 2010-11-11
Posts: 3,199
Website

Re: Performance Anxiety | custom_field loopiness

jakob wrote #290675:

I’m still unsure what the best caching strategies are, and whether txp-based or server-based is better (memcache?). I’d be interested in what people do or recommend.

I know nothing about server cache, having never developed a site heavy enough. I would use aks_cache for txp blocks involving much processing (tags clouds, complex menus), and also for external data, with noreset="1". But I would keep the number of aks_cache blocks reasonably small, at least in its present version.

Agreed, aks_cache just dumps the entire cache at present.

This is the point: aks_cache refresh is triggered by LastMod updates, which are not granular enough. Even if you update something (form, link, …) that has nothing to do with the cached block, it will be refreshed on the first visit. Whence my proposal to fire a detailed event in update_lastmod() function, to be able to refresh only appropriate cache blocks. This requires also some aks_cache plugin rewriting, but nothing spectacular.

Do you mean things like files and images that might be automatically included in article output without needing to update the article? I guess those would need excluding from long-duration cached blocks or they would not appear.

Not exactly, I mean that currently etc_ping acts only on article updates, ignoring other events (new comments, files, forms, …) that will update LastMod and yield “manual” aks_cache refresh.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#32 2017-03-16 20:52:30

etc
Developer
Registered: 2010-11-11
Posts: 3,199
Website

Re: Performance Anxiety | custom_field loopiness

I have written a cache plugin (4.6+ only) based on these ideas. It tries to be smart and trigger necessary cache updates when something (article, image, etc) gets changed.

The basic usage is

<txp:etc_cache id="heavycode">
<!-- heavy code -->
</txp:etc_cache>

The code will be processed and cached until the site is updated. On site update, the plugin will ping the url containing this block, triggering the cache refresh. Hence, the cache will always stay up to date, without penalizing site visitors.

If needed, one can pass time attribute to etc_cache:

<txp:etc_cache id="dailycode" time="+1 day">
<!-- daily code -->
</txp:etc_cache>

A positive (relative) value of time will indicate that the cache (even a fresh one) must be reset on site update. A negative value will not observe site updates. An absolute value like time='<txp:modified format="%F %T" gmt="1" /> +1 month' will mean “cache it if not modified since one month”.

You can be more specific with cache reset criteria. Say, if you need a block to be reset only if the article 3 is updated, edit (phpMyAdmin etc … currently Extensions tab) the following fields of etc_cache table:

reset: article_saved
filter: {"article_saved":{"ID":3}}

I will add have added an admin interface for this later.

Edit: download link


etc_[ query | search | pagination | date | tree | cache ]

Offline

#33 2017-03-17 20:31:13

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,487
Website

Re: Performance Anxiety | custom_field loopiness

I haven’t tried it yet, but this looks excellent. aks_cache and maniqui’s naming tips work well, but I’ve long wanted to make cache resetting a bit more intelligent.


TXP Builders – finely-crafted code, design and txp

Offline

Board footer

Powered by FluxBB