aks_cache: Partial caching web pages. SpeedUp your site!

makss · 2012-02-16 09:03:46

maniqui wrote:

Guillaume,
you could try this (not tested).
Replace lines 312-317 with:

         if($Status >= 4) {
              if ($oldArticle['Status'] < 4) {
                  do_pings();
              }
              update_lastmod();
          } else { 
            //New status is less than 4 (that is, it's not "live" nor "sticky")
              // Check if status for "old" article was "live" or "sticky"
              if ($oldArticle['Status'] >= 4) {  
                 // If so, update lastmod
                 update_lastmod(); 
              }
         }

simplify patch:

         if($Status >= 4 or $oldArticle['Status'] >= 4) {
              if ($oldArticle['Status'] < 4) {
                  do_pings();
              }
              update_lastmod();
          }

or add expires condition

         if( ($Status >= 4 or $oldArticle['Status'] >= 4)and (!$expires or $expires>=time()) ) {
              if ($oldArticle['Status'] < 4) {
                  do_pings();
              }
              update_lastmod();
          }

makss · 2012-02-16 09:22:03

Gocom wrote:

I wouldn’t recommend modifying core.
[skip]
Which can be loaded via a modular plugin content (plugin, theme etc).

Maybe it’s time to develop plugin such as abc_fixup-know-txp-core-bug ? ;-)

IMHO, it’s a core bug.
Switching an article’s status from “live” to “hidden” or “draft” – equivalent to the removal of articles from the frontend.
Removal of articles and references to it is a modification of content and should be reflected in the field lastmod.

Gocom · 2012-02-16 14:42:08

makss wrote:

IMHO, it’s a core bug.

Yes, didn’t say otherwise. Particularly whole update and caching model is lacking of features. Serves very little purpose of any site that get stream of new content. Things you get from having an open model.

wet · 2012-07-05 06:00:05

makss wrote:

IMHO, it’s a core bug.

Fixed in r3913.

I dismissed the $expired part because it didn’t play well with expired dates from the past.

mrdale · 2012-07-21 16:40:13

Using this plugin here… phtww.com and it really helps with page load times.

The main nav, pretty much cycles through every article on the site, so caching that part is really powerful.

I’ve been using the following approach for article forms.

<txp:aks_cache id='this-form-<txp:section/>-<txp:article_id/>'>Form Contents</txp:aks_cache>

This produces about 30 cached items.

Q: Is this too much? Ie are the benefits of caching going to decrease as I have more items cached?

nardo · 2012-10-30 22:51:05

I’m using etc_query to grab a feed from Instagram via their API. Works great. But often there are funky characters in photo captions. When I cache a block of content with aks_cache these characters cause the page to cease loading the html — when viewing source, the html stops where there is one of these (probably) invalid characters (represented as a square when I import it ‘live’).

I have tried cleaning the initial import without success; any suggestions from the cache side of things? or is it essentially a problem with the import?

whocarez · 2013-02-01 12:53:14

@makss

I wonder if it would be possible to integrate disk caching or more concrete: mem caching, to reduce the mysql load, because if you have several small pieces of a page in cache, for every piece you have to make a mysql query and that could possible slow down the site rendering, if your site has several parallel requests.
For example:
On a typical artical page, I have eight different aks_cache blocks and about 7000 entries in aks_cache. That means eight mysql queries per page.
The debug shows, that for page rendering 79 queries (maybe too much stuff) are made, so with disk/mem caching I could save these eight requests.
<!-- Memory: 6585Kb
Ok, maybe it sounds not worth it, but anyway if you have not two request a second, but five or more it could be a relevant speed factor. I mean for huge sites on textpattern not small blogs or something :-).

So as an alternative you could consider to offer as an option disk caching in memory, for example in /dev/shm/textpattern_cache or so …

In principle the good old zem_cache could fulfil this function, but I’m not sure if it is still working and it seems to me, that aks_cache is more flexible in use.
A problem is, that AFAIK only root users have rights to use /dev/shm on hosting plattforms, so standard directory for caching could be /textpattern/tmp, but then you depend not on memory speed, but on disk speed. Anyway I think disk/memory caching could speed up some sites.

makss · 2013-02-19 09:09:05

For busy sites and full page caching is ready solutions written in C, I would recommend using nginx with its wonderful cache

WEB users ==>  nginx(with cache manager)  ==> apache ==> Txp ==> MySQL

or

WEB users ==>  nginx(with cache manager)  ==> php-fpm ==> Txp ==> MySQL

On a typical artical page, I have eight different aks_cache blocks and about 7000 entries in aks_cache

A small note: the file system will be difficult to store over 2000-3000 files in one directory, so you need to provide for sharing of files into multiple directories.

There is a plugin rah_cache

One idea to reduce the load on MySQL.

jakob · 2015-08-28 11:00:04

Hi makss,

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>

I thought an aks_cache_disable block within it would permit this, but as far as I can tell the disabled section is dropped entirely from the cached block. Is that correct or am I using it wrongly? If so, how should I best deal with such a situation? split the cache block in two (or more) parts?

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.

etc · 2015-08-28 17:46:00

If I’m not mistaken, <txp:aks_cache_disable /> has no container mode, it’s only a switch disabling block cache. If you don’t mind relying on secondpass, you should be able to do the following (untested):

<txp:aks_cache id='article-<txp:article_id />'>
  … My article output …
  <txp:php>
    echo 'My dynamic <txp:tags /> and so on';
  </txp:php>
  … Rest of my article output …
</txp:aks_cache>

Edit: just remember that on the second pass the context may be different.

Last edited by etc (2015-08-28 17:55:35)

jakob · 2015-08-29 12:16:52

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…

etc · 2015-08-30 10:52:57

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.

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>

Textpattern CMS

Textpattern CMS support forum

#61 2012-02-16 09:03:46

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

#62 2012-02-16 09:22:03

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

#63 2012-02-16 14:42:08

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

#64 2012-07-05 06:00:05

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

#65 2012-07-21 16:40:13

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

#66 2012-10-30 22:51:05

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

#67 2013-02-01 12:53:14

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

#68 2013-02-19 09:09:05

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

#69 2015-08-28 11:00:04

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

#70 2015-08-28 17:46:00

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

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

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

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

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

jakob wrote #294419:

#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:

Board footer