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.

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:

Board footer