aks_cache: Partial caching web pages. SpeedUp your site!

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…

makss · 2010-06-29 08:17:20

New version aks_cache 0.2.6

Changes:

Add attribute disable
Add tag <txp:aks_cache_disable /> It’s used inside <txp:aks_cache> … </txp:aks_cache> block. Any cascade with txp:output form or other plugins for include form is allowed.

Last edited by makss (2016-01-16 18:53:35)

makss · 2010-07-01 07:02:24

Small update aks_cache 0.2.7

Changes:

Added option: “Disable cache for users”

Last edited by makss (2016-01-16 18:53:57)

ploinkr · 2010-07-20 14:32:38

Thanks makss! Just a quick question: will it work with TXP 4.0.8?

feragnoli · 2010-10-30 00:55:37

hello, thank you very much for this plugin, it’s very useful.
I have been experiencing some trouble, though.
I am caching a block containing a large gallery of images loaded from flickr.
I am not sure whether it is a timeout problem but what I get from the server is the following:

Tag error: <txp:aks_cache id='article <txp:article_id /> cache'> -> Textpattern Warning: MySQL server has gone away insert into claraaks_cache set hid='87210da0926103e97e8c6d28e706c5cb', ttl=1288413881, data='\n

… here follows the data to cache …

', infos='article 1 cache|240|8722' on line 85

I guess there’s a limit somewhere..?
thanks

Last edited by feragnoli (2010-10-31 00:34:41)

the_ghost · 2010-10-30 19:17:57

What size has chunk of code what you are trying. There is some mysql restriction that it can’t insert via php big parts – i had problem with inserting 2..3Mb code via aks_cache.

feragnoli · 2010-10-31 00:38:55

not sure about the size of it.
but IF it is caching the images too that must be a few Mb for sure. is there a way out of this? filesystem caching?
(where is the plugin saving the cache by the way?)

Textpattern CMS

Textpattern CMS support forum

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

#25 2010-06-29 08:17:20

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

#26 2010-07-01 07:02:24

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

#27 2010-07-20 14:32:38

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

#28 2010-10-30 00:55:37

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

#29 2010-10-30 19:17:57

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

#30 2010-10-31 00:38:55

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

Board footer