Textpattern CMS support forum

You are not logged in. Register | Login | Help

#71 2015-08-29 12:16:52

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

Re: aks_cache: Partial caching web pages. SpeedUp your site!

Thanks, Oleg, for the feedback. I’m not sure I understand why your suggestion works. Does that mean that all txp:php blocks in aks_cache won’t be cached? That would be useful/important to know.

I know that variables aren’t stored, so I’ve taken the route of defining the variable (in this case a viewing filter) above the cached block and including the variable’s value in the name of the cache block/id attribute. It means I end up with multiple cache blocks for the same part of the page depending on the viewing state but the caching works correctly at least.
Do you know if there is a point at which caching many blocks starts to introduce its own performance penalty… e.g. if lookup queries of the cached blocks exceed the sql queries one might have had in the page anyhow… I think Dale asked that earlier in this thread without there being an answer.

If I’m not mistaken, <txp:aks_cache_disable /> has no container mode, it’s only a switch disabling block cache.

I saw that too in makss’ description but wasn’t sure if it was just a language anomaly in the description (which is fairly sparse anyhow). There is a disable="1" attribute which would support that theory.
What’s the purpose of this tag then? Is this just a temporary “switch off this block while I debug” flag instead of having to remove/reinsert the aks_cache container tags? Or perhaps a way of disabling a block cache in certain if… conditions.

For the moment I solved my original problem by placing the dynamic code (the like button which changes values in the database but without resetting last_mod) at the bottom of my div block and caching only the top part while repositioning the element to the correct place with css. Not ideal and I end up with an aks_cache block for only part of a DOM element but it seems to work…


TXP Builders – finely-crafted code, design and txp

Offline

#72 2015-08-30 10:52:57

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

Re: aks_cache: Partial caching web pages. SpeedUp your site!

Hi Julian

jakob wrote #294419:

I’m not sure I understand why your suggestion works. Does that mean that all txp:php blocks in aks_cache won’t be cached? That would be useful/important to know.

No, they will be cached as well, but this particular <txp:php /> block does not parse <txp:tags />, only echoes it. So the literal content of the cached block output by <txp:aks_cache /> will be

… My parsed article output …
My unparsed dynamic <txp:tags /> and so on
… Rest of my parsed article output …

Now, the trick is that Textpattern parses its pages twice, so <txp:tags /> will be finally parsed on the second pass. But note that at that moment surrounding tags will be gone (parsed on the first pass), so the context can be quite different.

Do you know if there is a point at which caching many blocks starts to introduce its own performance penalty… e.g. if lookup queries of the cached blocks exceed the sql queries one might have had in the page anyhow… I think Dale asked that earlier in this thread without there being an answer.

There certainly is such a point, having thousands of cached block can slow things down. But just a hundred should be ok. If you explain what you mean by “viewing filter”, we could probably be more specific here.

What’s the purpose of <txp:aks_cache_disable /> then? Is this just a temporary “switch off this block while I debug” flag instead of having to remove/reinsert the aks_cache container tags? Or perhaps a way of disabling a block cache in certain if… conditions.

Yes, conditionals was my guess too, but makss certainly has a clearer idea of it.


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

Offline

#73 2015-08-30 13:02:02

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

Re: aks_cache: Partial caching web pages. SpeedUp your site!

Hi Oleg! Thanks for the brilliantly lucid reply. That clears things up for me much more and I learned something new in the process. That could be quite useful. I’d be interested to hear makss’ motivation for the disable tag.

There certainly is such a point, having thousands of cached block can slow things down. But just a hundred should be ok. If you explain what you mean by “viewing filter”, we could probably be more specific here.

Viewing filter: This particular site is a gallery for an artist. There’s a typical painting category chooser up front (7 categories + all = 8 ‘contexts’) and the visitor then flicks through the images sequentially, one after the other. A counter says “# of ##” at the bottom and there’s also the possibility to “like” a painting. The artist has a subset of his paintings publicly viewable and can send selected visitors a link to see the full selection of paintings. Each painting is marked as sold or available and the viewer can filter by either or none. So essentially there are three viewing filters at any one time:

  1. 8 category contexts = 7 cats + “all”
  2. an all | sold | available filter
  3. a (hidden) full | public selection filter

The painting template therefore has to determine the combination of filters from the url/cookie, calculate the total number of matching paintings for that combination (an article_custom query into an id-list plus a bit of php to get the length of the list) and work out what position the current painting is in that list and determine the links for the next and prev paintings in the list. The latter uses the next/prev id in the list but requires two further article_custom calls to get the respective permlinks. So while the actual painting and its metadata is the same for that painting the “# of ##” counter, the like counter and the next/prev permlinks are dynamic depending on the “viewing” context, e.g. four article(_custom) calls are required to display one image: the painting data, the article-id-list and the next and prev permlinks.

My caching strategy has therefore been to cache:

  • artwork : id# – caches painting and related metadata that doesn’t change with context
  • artwork : id# : nextprev {category} {sold_status} {full_public} – caches two article_custom calls in potentially 8 × 3 × 2 = 48 combinations per painting
  • artwork-id-list : {category} {sold_status} {full_public} – caches the article id list for each context situation – potentially 8 × 3 × 2 = 48 – in all (not per painting). Essentially this turns the article_custom output into a persistent variable.

In the full collection there are currently 218 paintings with a few more to come, i.e. the maximum number of cache blocks is: (218 × 1) + (218 × 8 × 3 × 2) + (8 × 3 × 2) = 1574, although it is rare that every permutation would ever be generated. The blocks are all very tiny. There are currently 95 images in the public selection which more than halves the number to 713. I do see a noticeable improvement in loading time, although it is the image that always takes longest to load anyhow.

Possible optimisations:

  • I could conceivably cache every painting in every combination: 218 or 95 × 8 × 3 × 2 = 1308 (full) or
    570 (public selection) potential cache blocks. For that I would need to bracket out the “like” button from the cache block, possibly using your txp:php + echo txp-tag combination, but the cache blocks themselves would be larger…
  • I could drop caching the paintings themselves (it’s really just the txp_image lookup and article metadata so the speed savings may be nearly negligible) and save 218 or 95 cache blocks, e.g. 1356 (full) / 618 (public) cache blocks.

But ideally, I’d rather just have a cache block for each painting plus perhaps for each of the article-id-list combinations (they only every change when a new painting is added or edited) and to generate the “# of ##” and next/prev links as “holes” of dynamic content within that cached block. That would reduce the cached block count to 218+48 = 266 or 95+48 = 143…

Still with me? I’m not sure you wanted so much detail, but now you can see why I asked ;-)


TXP Builders – finely-crafted code, design and txp

Offline

#74 2015-08-30 15:24:06

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

Re: aks_cache: Partial caching web pages. SpeedUp your site!

jakob wrote #294434:

But ideally, I’d rather just have a cache block for each painting plus perhaps for each of the article-id-list combinations (they only every change when a new painting is added or edited) and to generate the “# of ##” and next/prev links as “holes” of dynamic content within that cached block. That would reduce the cached block count to 218+48 = 266 or 95+48 = 143…

That’s what I’d do too, but the solution depends on your url scheme and the desired prev/next links format (only “Prev/Next” or “Prev/Next title”), because using <txp:permlink /> or <txp:article_custom /> would mean two extra db queries. But is the nocache construction really that slower?


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

Offline

#75 2015-09-01 15:52:56

makss
Plugin Author
From: Ukraine
Registered: 2008-10-21
Posts: 355
Website

Re: aks_cache: Partial caching web pages. SpeedUp your site!

jakob wrote #294411:

I have a situation where I’d like to cache a block but allow a few small elements within it to remain dynamic, e.g.:

<txp:aks_cache id='article-<txp:article-id />'>
  … My article output …
  <txp:aks_cache_disable>
    … My “Like this article” button using cbe_helpful …
  </txp:aks_cache_disable>
  … Rest of my article output …
</txp:aks_cache>

Thanks for the idea, and later I will try to implement it. Ie to display dynamic content on the second pass.

Also: is it – or would it be – possible to make cache time persist until the next manual or last_mod reset? e.g. by setting ‘Default cache time in minutes’ to 0 or empty.

Yes it can be done. Usually I just point out 365 days. :)

By the number of entries in the cache: I have several years of work site with Items In cache: 10354 – It works quickly.

Now the tag <txp: aks_cache_disable /> is not very obvious application. It was designed for use in enclosed forms or prohibition cache on some condition.

Example 1

<txp:aks_cache id='section_<txp:section />'>
	<txp:output_form form='sec_<txp:section />' />
</txp:aks_cache>

Form: sec_some1

Do not cache anything that uses this form.
<txp:aks_cache_disable />

Example 2

<txp:aks_cache id='article-<txp:article-id />'>
	… My article output …
	<txp:if.... >
		These articles will not be cached
		<txp:aks_cache_disable />
	</txp:if...>
</txp:aks_cache>

aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)

Offline

#76 2016-02-06 13:10:43

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

Re: aks_cache: Partial caching web pages. SpeedUp your site!

Would it be possible to add a more fine-grained way of optionally controlling how the cache is cleared? Perhaps on a per-article basis rather than blanket last_mod making everything update?

The situation is a site with thousands of articles that is updated regularly, often every few days. The old articles remain unchanged and the cache for those could persist for a long time without needing to be cleared.
Or is there a better alternative way of doing this?

BTW: what has changed with the most recent version of aks_cache?


TXP Builders – finely-crafted code, design and txp

Offline

#77 2017-06-12 13:03:44

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 3,192
Website

Re: aks_cache: Partial caching web pages. SpeedUp your site!

Does this work with Textpattern 4.7dev? Can’t seem to get it working on my local site test.

Offline

#78 2017-06-12 18:34:30

makss
Plugin Author
From: Ukraine
Registered: 2008-10-21
Posts: 355
Website

Re: aks_cache: Partial caching web pages. SpeedUp your site!

philwareham wrote #305925:

Does this work with Textpattern 4.7dev? Can’t seem to get it working on my local site test.

Oops, does not work anymore. ;-)
Thanks for the report, I will fix it soon.


aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)

Offline

#79 2017-06-12 20:25:52

makss
Plugin Author
From: Ukraine
Registered: 2008-10-21
Posts: 355
Website

Re: aks_cache: Partial caching web pages. SpeedUp your site!

aks_cache 0.3d

Changes:

  • Textpattern 4.7dev Fix

aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)

Offline

#80 2017-12-01 16:58:11

Manaus
Member
From: Turin, Italy
Registered: 2010-10-22
Posts: 244
Website

Re: aks_cache: Partial caching web pages. SpeedUp your site!

I’ve tried to put <txp:aks_cache id='article-<txp:article_id>'> around the article tag, but I get always the same article. Seems like the pattern does not recognize the <txp:article_id> modifier. In fact in the cache list I have article- as the corrisponding handler. So no matter what I click on, I get always the same article. I tried also to put <txp:aks_cache> without id, since it should get the URI as identity, but I get as well the same article.
Thanks for any suggestion

Offline

Board footer

Powered by FluxBB