Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#25 2015-04-10 21:08:37

giz
Member
From: New Zealand
Registered: 2004-07-26
Posts: 259
Website

Re: Performance Anxiety | custom_field loopiness

etc wrote #289510:
  1. Install aks_cache and check Reset cache if site was updated preference on aks_cache tab.
  2. Wrap your code in some long-living aks_cache block, with noreset="".
  3. Install and activate etc_ping (below), and fill etc_ping field in Advanced Preferences with one or several comma-separated URLs where your aks_cache block(s) is (are) visible.

If my aks_cache code block appears on every page, what should I enter in etc_ping’s field in Advanced Preferences?

A minor issue: etc_ping’s preferences do not appear under 4.6dev. I know how to get around this!

Thank you.

Offline

#26 2015-04-10 21:21:50

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Performance Anxiety | custom_field loopiness

giz wrote #289901:

If my aks_cache code block appears on every page, what should I enter in etc_ping’s field in Advanced Preferences?

Any page will do, if aks_cache blocks share the same id.

A minor issue: etc_ping’s preferences do not appear under 4.6dev. I know how to get around this!

Please share, I’m not (yet) very familiar with 4.6.

Offline

#27 2015-04-10 22:08:57

giz
Member
From: New Zealand
Registered: 2004-07-26
Posts: 259
Website

Re: Performance Anxiety | custom_field loopiness

Thanks.

etc wrote #289902:

Please share, I’m not (yet) very familiar with 4.6.

Nothing spectacular: I’ve installed etc_ping on my 4.5.7 site, and plan on copying the relevant prefs over to my 4.6dev performance-testing installation, via phpmyadmin.

.

Or did you mean “explain the bug”? In my 4.6dev install there is no ‘advanced prefs’ tab – every preference (other than etc_ping) is shown in a large list, broken down by toggle-able sections. No mention of etc_ping in the source either. I hope this helps!

Last edited by giz (2015-04-10 22:15:34)

Offline

#28 2015-05-11 15:49:29

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: Performance Anxiety | custom_field loopiness

etc wrote #289510:

Now, why not to update aks_cache automatically, on each article post/save?

I’ve been adding a series of aks_cache blocks to a website and it makes a real difference, especially where tag use is intensive. But like you mention, the cache only persists for as long as the cache time (default = 60 mins) and has to be regenerated from scratch at intervals although nothing has changed. It could, however, conceivably remain cached until the next page update.

From your description, etc_ping sounds like it would be ideal, but I’m not sure if I understand the concept: am I right in assuming that when you save or post an article, etc_ping causes the pages listed in the etc_ping pref to be ‘visited invisibly’, causing aks_cache to refresh those cache blocks in that moment (rather than when the next person happens to call up that page)? In other words, you’re the one doing the ‘waiting’ before someone else has to.

I presume you then need to put http://www.domain.com/apples/,http://www.domain.com/oranges/,http://www.domain.com/category/fruit,… and so on in the pref, which can get quite long if you happen to have an extensive site (or can you do just /apples,/oranges,/category/fruit,…?).

Would it be possible to somehow refresh just certain aks_cache blocks, based on the article that is being saved, e.g. in the same section, or a designated section (occasionally I use sections to input data, but display it on another section)? Or would that not work, because any change to lastmod will cause aks_cache to dump its entire cache?

Finally, could the plugin be made to hook into some other event. I’m thinking of data brought in from a non-txp source, e.g. using your own etc_query?

Also, out of interest, what would you recommend as a long refresh interval: how large is a good large value: one month of minutes? one year of minutes?


TXP Builders – finely-crafted code, design and txp

Offline

#29 2015-05-11 17:50:29

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Performance Anxiety | custom_field loopiness

jakob wrote #290654:

From your description, etc_ping sounds like it would be ideal, but I’m not sure if I understand the concept: am I right in assuming that when you save or post an article, etc_ping causes the pages listed in the etc_ping pref to be ‘visited invisibly’, causing aks_cache to refresh those cache blocks in that moment (rather than when the next person happens to call up that page)? In other words, you’re the one doing the ‘waiting’ before someone else has to.

Yes, absolutely, etc_ping “visits” the supplied URLs on article updates, triggering aks_cache refresh (if present on the page).

I presume you then need to put http://www.domain.com/apples/,http://www.domain.com/oranges/,http://www.domain.com/category/fruit,… and so on in the pref, which can get quite long if you happen to have an extensive site (or can you do just /apples,/oranges,/category/fruit,…?).

Still yes, but it can be easily adapted to include “local” URLs.

Would it be possible to somehow refresh just certain aks_cache blocks, based on the article that is being saved, e.g. in the same section, or a designated section (occasionally I use sections to input data, but display it on another section)? Or would that not work, because any change to lastmod will cause aks_cache to dump its entire cache?

This could be done, though you are right, the blocks not updated by etc_ping will be updated (unless they are noreset) by the first visitor. One needs to modify aks_cache to fix this.

Finally, could the plugin be made to hook into some other event. I’m thinking of data brought in from a non-txp source, e.g. using your own etc_query?

I’ve raised an issue for other txp events, but haven’t thought of “custom” updates. Updates should not be triggered by visitors, otherwise there is no point in etc_ping, but etc_query is public-side… don’t know. You can wrap “external” data in <txp:aks_cache noreset="1" /> lasting, say, 59 minutes, and subscribe the appropriate pages to some free web monitoring service with 1h interval. But their synchronization is tricky.

Also, out of interest, what would you recommend as a long refresh interval: how large is a good large value: one month of minutes? one year of minutes?

After a week, txp sends the current date as Last-Modified (bug? feature?) even if nothing was modified, so more than one week seems pointless, but txp LastMod is not changed, so whatever you want.

Note: etc_ping will be pretty useless if you often update other things than articles, unless we subscribe it to more callbacks.

Last edited by etc (2015-05-11 20:38:05)

Offline

#30 2015-05-12 07:56:42

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: Performance Anxiety | custom_field loopiness

Thanks for the brilliant and informative reply! For sites that are only updated sporadically – perhaps a couple of blog articles a month etc. – then a cache update on article update would be fine, I think. The only real ‘problem’ is when making site changes, but after development that is less frequent.

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. At present I do:

  • cache distinct chunks of a homepage built with txp-tags (anything that involves several db queries) using aks_cache
  • name chunk ids/blocks to be granular enough to cover all the different display situations (e.g. different active states on different pages), but common enough to avoid creating duplicate identical chunks (e.g. sidebar article menus per year not created for every article in that year).
  • not cached: straightforward txp:article output unless it brings in lots of associated data (e.g. image galleries, link lists, file downloads via custom fields).
  • not cached: information sourced from other sites that has its own update rhythm (e.g. twitter feed etc. – for that I’m using tweetledee for that which has its own caching).

Refresh just certain aks_cache blocks, based on the article that is being saved, e.g. in the same section, or a designated section … This could be done, though you are right, the blocks not updated by etc_ping will be updated (unless they are noreset) by the first visitor. One needs to modify aks_cache to fix this.

Agreed, aks_cache just dumps the entire cache at present.

Note: etc_ping will be pretty useless if you often update other things than articles, unless we subscribe it to more callbacks.

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.


TXP Builders – finely-crafted code, design and txp

Offline

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

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

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.

Offline

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

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

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

Offline

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

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
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