aks_cache: Partial caching web pages. SpeedUp your site!

maniqui · 2010-05-06 03:58:06

This is even weirder than I would have expected.
On some other place, I’m using two aks_cache blocks that are almost identical in content, and in both blocks I’m using something like this.

   <txp:aks_cache id='sectionA_<txp:article_id />'>

   <txp:aks_cache id='sectionB_<txp:article_id />'>

For sectionA, the cache blocks are created properly: sectionA_1, sectionA_2, sectionA_3, etc.

But for sectionB, the cache block is created as: sectionB_.

I can’t spot any differences (beside some different HTML/TXP tags on the inside of each aks_cache block).

makss · 2010-05-06 08:56:23

maniqui wrote:

<txp:aks_cache id='site_vars_<txp:section />'>
  <txp:variable name="body_id"><txp:pax_grep from="'-'" to="_">s_<txp:section /></txp:pax_grep></txp:variable>
  <txp:variable name="body_class"><txp:pax_grep from="'-'" to="_">s_<txp:section /></txp:pax_grep></txp:variable>
</txp:aks_cache>

Hint: <txp:variable name="body_id" value="123" /> tag stores only in memory as PHP variable and this can’t be cached.

For debug, please add <txp:section /> tag in your block, same as:

<txp:aks_cache id='otf_css_<txp:section />' noreset="1">
  <!-- On-the-fly styles for highlighting active section =<txp:section />= -->
  <style type="text/css">
    .<txp:variable name="body_id" /> #nav_<txp:variable name="body_id" /> a {
      color:#95292c;
    }
  </style>
</txp:aks_cache>

What version of TxP is used? Maybe need set some section as default (admin tab Sections)?
Please run this simple test:

1=<txp:section />=1
<txp:variable name="body_id">2=<txp:section />=2</txp:variable>
<txp:variable name="body_id" />
<txp:variable name="body_id2" value='3=<txp:section />=3' />
<txp:variable name="body_id2" />
<txp:if_section name="">
4=<txp:section />=4
</txp:if_section>

My output is: 1=default=1 2=default=2 3=default=3 4=default=4
and block for “no section” created as otf_css_default

makss · 2010-05-06 09:09:41

maniqui wrote:

<txp:aks_cache id='sectionB_<txp:article_id />'>

For sectionA, the cache blocks are created properly: sectionA_1, sectionA_2, sectionA_3, etc.
But for sectionB, the cache block is created as: sectionB_.

It used in individual_article or article listing?
Maybe need use it:

<txp:if_individual_article>
<txp:aks_cache id='sectionB_<txp:article_id />'>...</txp:aks_cache>
</txp:if_individual_article>

makss · 2010-05-06 09:27:56

Possible, it’s a bad practice… but your can, not set id attribute.
By default id = $_SERVER["REQUEST_URI"]

Limitation for “not set id attribute”: one unique block per page.

Maybe in next version aks_cache need add attribute block ?
for using aks_cache witout id attribute same as:

<txp:aks_cache block="block1">123</txp:aks_cache>
<txp:aks_cache block="block2">456</txp:aks_cache>

on page http://domain.com/section1/page1 this create blocks:

block1/section1/page1
block2/section1/page1

Upd: New version aks_cache 0.2.5

Changes:

Add attribute block

Now, all examples in this post is available. :)

Last edited by makss (2016-01-16 18:52:58)

sereal · 2010-05-06 14:35:33

this is wonderful !

maniqui · 2010-05-06 15:15:06

makss wrote:

Hint: <txp:variable name="body_id" value="123" /> tag stores only in memory as PHP variable and this can’t be cached.

Good to know.

What version of TxP is used? Maybe need set some section as default (admin tab Sections)?

4.2.0. No, on TXP you don’t have to set a “default” section. On “Sections” tab, you can define which section will be selected by default (on the Write tab dropdown menu) or you can select which template/css will use the “default” section (aka, the root domain), but there is no concept of “choose a ‘default’ section”.

Please run this simple test:
My output is: 1=default=1 2=default=2 3=default=3 4=default=4

Same output here.

and block for “no section” created as otf_css_default

Not sure what you mean here by “no section”.

Thanks.

maniqui · 2010-05-06 15:17:06

maniqui wrote:

<txp:aks_cache id='sectionB_<txp:article_id />'>

For sectionA, the cache blocks are created properly: sectionA_1, sectionA_2, sectionA_3, etc.
But for sectionB, the cache block is created as: sectionB_.

makss wrote:

It used in individual_article or article listing?

Both are being used on individual_article listing, taking the advantage that article tags like article_id are available to the template when in individual-article.

Maybe need use it:

<txp:if_individual_article>
<txp:aks_cache id='sectionB_<txp:article_id />'>...</txp:aks_cache>
</txp:if_individual_article>

Will try it that too, to see if it makes any differences.

maniqui · 2010-05-06 15:23:13

makss wrote:

Upd: New version aks_cache 0.2.5

Thanks! I’ll try it asap, and will check if the new block attribute let us also do some tags-in-tags magic with better/more-predictable behavior than when using the id attribute.

BTW, regarding the original problem, where ids like css_<txp:section /> were creating two cache_blocks (the correct css_mysection, and the incorrect css_), I’ve tested further and noticed that it doesn’t happens in every section.
In other words, there are some sections that never create the wrong css_ cache-block, while there are other sections that always triggers this bad behavior.
I haven’t been able to find out any difference (in code) that would be the cause of this different behavior.

maniqui · 2010-05-07 14:50:31

Hi makss,

After playing a little more with this plugin, I have some questions about its usage and best practices.

Suppose I would like to cache some secondary widgets (small boxes of dynamically generated content, on the sidebar).
Suppose also that I use a few forms for managing each form.
So, I’v somethinge like this:

On page template:

<div id="secondary">
<txp:output_form name="widget-A" />
<txp:output_form name="widget-B" />
<txp:output_form name="widget-C" />
</div>

And each form, widget-A, widget-B and widget-C, is something basic, like this:

<div class="widget">
... some TXP tags and conditionals here...
</div>

Now, the question is. Should I get better results by caching the whole column?
Like this:

<div id="secondary">
<txp:aks_cache block="widgets">
<txp:output_form name="widget-A" />
<txp:output_form name="widget-B" />
<txp:output_form name="widget-C" />
</txp:aks_cache>
</div>

Or by caching each widget? Like this:

<div class="widget">
<txp:aks_cache block="widget-A">
... some TXP tags and conditionals here...
</txp:aks_cache>
</div>

Of course, I’m simplifying things a lot, as it may be other things to take into consideration.

For example, I’ve found that it’s not “reliable” to cache a block of TXP tags if there are a few conditionals inside, like if_section, as those conditionals won’t get evaluated after the block is cached. So if serving a block of content on two different situations (ie. two different sections), and that block renders different content depending on the section, then just caching it will get undesired results.

Of course, there is a workaround, and it’s to create unique, URL-dependent, cache-blocks, particularly by using the new block attribute…

So, this are just a few aloud thoughts about my experiences so far with this nifty plugin.

Thanks again.

the_ghost · 2010-05-07 17:00:35

I’ve found that it’s not “reliable” to cache a block of TXP tags if there are a few conditionals inside, like if_section, as those conditionals won’t get evaluated after the block is cached. So if serving a block of content on two different situations (ie. two different sections), and that block renders different content depending on the section, then just caching it will get undesired results.

aks_cache will work in this case if block’s content is url-sensetive, i.e. at url site.ru/article/first-article and site.ru/about/bio you txp-code returns different results. Than at each page their would be created cache with different id – like it works at my site.

maniqui · 2010-05-07 17:21:29

Yes, Victor, you are right. In fact, I also said:

Of course, there is a workaround, and it’s to create unique, URL-dependent, cache-blocks, particularly by using the new block attribute…

I wonder also if there may be any issues (particularly, destroying the space-time continuum) if nesting aks_cache blocks. For example, caching each widget, and also, in some templates, caching a whole div that contains all those already cached widgets.

the_ghost · 2010-05-07 17:56:30

In fact, the only issue will be if you have user-generated stuff and you will cover this if with aks_cache. For example, looking for browser and giving different content – you should place aks_cache in this case inside browser checking, otherwise you will show ever content generated for old visitor with his own browser.

At on of my sites i placed aks_cache everywhere i saw complex db-queries or complex php-scripts. As result – querytime downs from 0.7 to 0.2 sec, and php-generation time downs from 0.8 to 0.3 sec. And i have some more places where to save more time – but this parts of code are rather complex-generated…

Textpattern CMS

Textpattern CMS support forum

#13 2010-05-06 03:58:06

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

#14 2010-05-06 08:56:23

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

#15 2010-05-06 09:09:41

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

#16 2010-05-06 09:27:56

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

#17 2010-05-06 14:35:33

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

#18 2010-05-06 15:15:06

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

#19 2010-05-06 15:17:06

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

#20 2010-05-06 15:23:13

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

#21 2010-05-07 14:50:31

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

#22 2010-05-07 17:00:35

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

#23 2010-05-07 17:21:29

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

#24 2010-05-07 17:56:30

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

Board footer