aks_cache: Partial caching web pages. SpeedUp your site!

jakob · 2015-08-30 13:02:02

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:

8 category contexts = 7 cats + “all”
an all | sold | available filter
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 ;-)

etc · 2015-08-30 15:24:06

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?

makss · 2015-09-01 15:52:56

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>

jakob · 2016-02-06 13:10:43

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?

philwareham · 2017-06-12 13:03:44

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

makss · 2017-06-12 18:34:30

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.

makss · 2017-06-12 20:25:52

aks_cache 0.3d

Changes:

Textpattern 4.7dev Fix

Manaus · 2017-12-01 16:58:11

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

etc · 2017-12-01 16:59:32

Is your <txp:article_id> closed, i.e. <txp:article_id />?

Manaus · 2017-12-01 17:21:23

Damn it was article-id >:~)

gilibaus · 2019-02-12 23:43:53

I have a website where every week I publish a podcast episode in the form of an article containing some text + an audio player. The old episodes (approximately 100 and counting) remain unchanged. Is it a suitable scenario for aks_cache? Thanks.

Last edited by gilibaus (2019-02-13 08:29:07)

jakob · 2019-02-13 16:31:27

I’m not an expert on this, so maybe someone more knowledgeable can give you a more qualified answer.

However, as I understand it, caching plugins help save pre-rendered page content that doesn’t change much. They save Textpattern going back to the database and processing a page, so their main benefit is in speeding up pages with complex content and lots of database queries. Pages with complex menus or long categorised lists compiled from many posts probably benefit most.

I don’t think it has any benefit for serving files such as audio files, so it’s unlikely to speed that up.

aks_cache is good, but if you make one change to the site, the entire cache is discarded and rebuilt in subsequent site visits. etc_cache is better in this respect in that you can set it only to discard the relevant bit of the cache. I don’t think it works with older versions of textpattern, though.

One thing you need to watch out for when using a caching plugin is to name your cache blocks sensibly for every possible view of a page, e.g. if you can filter your list of articles by category, make sure a separate cache block is created for each category view or you may find the cache blocks your filter from working.

Textpattern CMS

Textpattern CMS support forum

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

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

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

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

jakob wrote #294434:

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

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

jakob wrote #294411:

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

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

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

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

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

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

philwareham wrote #305925:

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

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

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

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

#81 2017-12-01 16:59:32

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

#82 2017-12-01 17:21:23

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

#83 2019-02-12 23:43:53

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

#84 2019-02-13 16:31:27

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

Board footer