aks_cache: Partial caching web pages. SpeedUp your site!

mericson · 2011-11-27 15:50:24

How does aks_cache deal with conditionals in the content? <txp:if_section… <txp:if_search…. etc. ?

Do I need to avoid caching any portions of my textpattern markup if it contains conditional ? I suppose it is fine for some conditionals, because the conditional logic is deterministic based on the URL.

mericson · 2011-11-27 15:52:00

I agree, seems like file-system cache would be a nice enhancement. For me, the reason I want to cache is that my bottleneck can be a shared MySQL instance. If the performance of the database degrades dramatically, I won’t be as impacted if I have file caching !

stephan wrote:

Is it possible to set aks_cache so it uses a directory to write cache files to instead of using the MySQL database?

Last edited by mericson (2011-11-27 16:28:14)

merz1 · 2011-11-28 08:21:22

The keywords to look for are ‘full page caching’. There is a plug-in and a feature request too.

stephan · 2011-11-28 08:42:15

Hi Markus,

full page caching is a different approach. It seems only the orpahaned zem_cache would be able to do partial page caching to file (what I would look for rather than caching a full page), asy_jpcache only caches the full page indeed.

Now my use case is to cache the database intense tag cloud in a file, also the last comments part in the side bar, so now full pages but only partial blocks, just like aks_cache does – but saved in a file instead of the database table.

Can we upvote the existing feature request? ;-)

merz1 · 2011-11-30 08:13:35

Sorry Stephan, my quick answer was aimed at Mark because he talked about bad database responses in another forum thread and I threw both issues together. Of course full page caching is a totally different (and much faster) approach.

maniqui · 2011-12-01 00:07:01

Hi all.

To grok this plugin, you have to understand how to cleverly use/combine the id and block attributes, that seem (and maybe, in some cases, are) a bit redundant…

Quick background

The id attribute defaults to the requested URI.
So, if you put something like this in your form/page, and then visits some URL (i.e. a section, an article):

<txp:aks_cache>
... some txp tags that outputs dynamic content fetched from database...
</txp:aks_cache>

It will create a “cached chunk of content” with a unique name. For example, if you visited /sectionA/, it will create a chunk named /sectionA/; if you visited /sectionA/some-article, it will create a chunk named /sectionA/some-article, and so on.

Limitation: using <txp:aks_cache> without id or block attributes won’t let you have more than one cached chunk of content per page. It’s highly probably that you don’t want to do that (ie. you want to cache a few different chunks of contents here and there on the same page), so let’s go on.

That’s when the attribute block comes in handy, and may be a better choice than overriding the id attribute.
When using the block attribute, you can have different chunks of contents cached, each one with its own particular name. Combining this with the id attribute (setting it to different values) opens up a few possibilities…

These are my usage tips and use cases for this plugin:

1. Caching chunks of dynamically-generated content on a per-URL basis

Simple, wrap your txp tags with <txp:aks_cache block="some_content">. Like this:

<txp:aks_cache block="my_dynamic_widget_of_latest_articles">
... some txp:tags here, like article_custom and if_article_id, or if_section, etc...
</txp:aks_cache>

As you can see, the id attribute is implicit, so it will default to requested URL. That means that this code will create a cached chunk for each visited URL that renders the widget. Like:

my_dynamic_widget_of_latest_articles/sectionA/
my_dynamic_widget_of_latest_articles/sectionA/some-article
my_dynamic_widget_of_latest_articles/sectionA/some-other-article
my_dynamic_widget_of_latest_articles/sectionB/my-article
my_dynamic_widget_of_latest_articles/sectionB/
my_dynamic_widget_of_latest_articles/ (this one corresponds to the homepage, see bonus tip below)
etc

This usage pattern is ideal for caching code that has conditional logic determined by changes in URL (as mericson noted). For example, a “latest articles” widget that, when on individual article, highlights the current one.

Another usage case: you want to create a cache of the rendered article for each permlink (where the article is, usually, the main content), so you do this:

<txp:aks_cache block="main_content">
  <txp:article form="default" /> <!-- or you could use txp:article as container -->
</txp:aks_cache>

The chunks of cached content that will be created are like:

main_content/sectionA/some-article
main_content/sectionA/some-other-article
main_content/sectionB/my-article
etc

Final tip on this usage pattern: I find it better to apply it at a page template level, for example, wrapping your <txp:article> or <txp:article_custom> tags. But YMMV, as this depends on the way you like to code your pages & forms.

2. Site-wide cacheing

Use case: to cache some content once and then use that piece of cache site-wide, that is, in different pages. For example, a list of articles (simple version, without any fancy highlighting), or a widget with latest tweets (fetched with a server-side mechanism, like arc_twitter), or a category listing, etc

<txp:aks_cache id="" block="some_widget">
... some txp:tags here, like article_custom, category_list, arc_twitter, etc
</txp:aks_cache>

Notice that the id attribute is set to empty. This will cause that the cached chunk of content gets this simple name: some_widget.
As you can see, this name doesn’t have anything that relates the cached chunk to a particular URL. That’s good for this usage case.

In this usage pattern, I find it better to use the <txp:aks_cache> tag at a form level. For example, you have this “twitter_widget” form:

<txp:aks_cache id="" block="twitter_widget">
  <txp:arc_twitter />
</txp:aks_cache>

Then, on your page templates, you simple use good ol’ <txp:output_form form="twitter_widget" />.
As you can see, the <txp:aks_cache> is inside the form, instead of wrapping the <txp:output_form /> tag (which would have worked anyway). This way, you greatly reduce the number of times that you have to write the <txp:aks_cache> tag.

3. Using noreset, and hour/min attributes

For some widgets, like the “twitter_widget” in previous example, it could help to enable the noreset attribute, to avoid the cached chunk to be flushed when reseting the cache. At the same time, for this particular “twitter_widget” example, it may be wise to set a different (lower) value for the hour and/or min attributes, supposing that you tweet more often than you update your website :)

4. Bonus tip: on homepage, use id=”/home”

If you are caching some chunks of contents that are specific to your homepage, I’d suggest you to do it like this:

<txp:aks_cache id="/home" block="some_content">
... content...
</txp:aks_cache>

This way, in the “Extensions -> aks_cache” tab, it will appear listed as some_content/home, instead of some_content/.
What’s the gain? Easier to read, that’s all.

TO-DO

Let’s investigate:

good values for “Default cache time”: this may probably vary from site to site, according to update frequency and other variables. Would it be good to set a really high value for this variable? It seems so, particularly if used combination with the “Reset cache if site was updated” option (enabled)
clever use of tags-in-tags (using txp:tags as values for aks_cache attributes)
what else?

jakob · 2011-12-01 07:28:12

Thanks maniqui, that was most informative!

hablablow · 2011-12-01 08:54:39

Julian,

Cool initiative but:

As you can see, the id attribute is implicit, so it will default to requested URL.

ID ? Where ?

Last edited by hablablow (2011-12-01 08:55:52)

maniqui · 2011-12-01 13:25:19

Hi Guillaume.

I wanted to mean that the id attribute on txp:aks_cache, as it’s not explicitly (ie. it’s tacit/implicit) set to any value, it will default to the request URL.

hablablow · 2011-12-01 18:48:14

Okay Julian…
Related: did you experience some hickups with this plugin. Sometimes I suspect the cache is either not flushed or is not rebuilt properly…

maniqui · 2011-12-01 19:32:44

Do you have any theory for your suspicions?

Not that I can recall but… now that you mention, something similar (cache not being flushed/rebuilt properly) happened to me, but the culprit was not the plugin.
This is what I was perceiving: right after hitting the “reset cache” (or “clear all cache”) button, the aks_cache tab reloaded, and there were a few cache “leftovers”. How could that be possible if I just cleared the cache and didn’t visit the front-end, so it couldn’t be generating a new cache?

Checking the Network tab on Web Inspector show me the light: after hitting the “reset cache” (or “clear all cache”) button, the admin page gets reloaded. I noticed, in the Network tab, that a few images used in admin source (the carver and others) were missing, thus, when requested, they generated a 404 in TXP. That 404 page, managed by TXP, also included some aks_cache code (for caching widgets). So, what I perceived as “leftovers” were, in reality, new cache chunks generated right instantly after I cleared the cache.

May something similar be happening to you?

hablablow · 2011-12-01 19:58:39

I’m not sure if this is the cause…
Since I know you’ve investigated a lot on this plugin I wanted to make sure you didn’t cross this behaviour as well…
I’ll keep your answer in mind so I can reference it if I cross this problem again…
Thanks !

Last edited by hablablow (2011-12-01 19:59:55)

Textpattern CMS

Textpattern CMS support forum

#37 2011-11-27 15:50:24

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

#38 2011-11-27 15:52:00

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

#39 2011-11-28 08:21:22

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

#40 2011-11-28 08:42:15

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

#41 2011-11-30 08:13:35

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

#42 2011-12-01 00:07:01

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

Quick background

1. Caching chunks of dynamically-generated content on a per-URL basis

2. Site-wide cacheing

3. Using noreset, and hour/min attributes

4. Bonus tip: on homepage, use id=”/home”

TO-DO

#43 2011-12-01 07:28:12

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

#44 2011-12-01 08:54:39

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

#45 2011-12-01 13:25:19

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

#46 2011-12-01 18:48:14

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

#47 2011-12-01 19:32:44

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

#48 2011-12-01 19:58:39

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

Board footer