Cache expiry after new content being published

Previous topic

Setup & design

Next topic

Author	Message
Piotrek Karaś	Thursday 19 April 2007 1:00:04 pm Hello there, I do realize, that similar questions might have been asked before, but cache issues seems to have been the most troublesome issue of eZ publish, judging by the amount topics the search returns... After some time I just gave up... The best way I have so far discovered to measure and observe the installation's efficiency when it comes to cache tasks is to display the debug information below the pagelayout and check the amount (or time) of SQL queries. When we clear the entire cache, our sites generate up to 200 of queries (by the way - is that common?), but then each next request only needs just a few (up to 10), depending on which pagelayout parts we decided to leave uncached. It all goes ok until next piece of content is published - no matter where in the content structure menu - it causes the template to require almost the initial amount of queries to be sent again, just before it gets cached again. I don't expect any detailed info here. Just would like to know if it is a regular eZ publish behavior to expire most of its cache when new content is published? Or is it just my misconfiguration or bad planning? -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
André R.	Friday 20 April 2007 4:05:34 am Hi! Take a read on: http://ez.no/doc/ez_publish/technical_manual/3_8/reference/template_functions/miscellaneous/cache_block On cache blocks that don't have to expire right away when new content is published I would recommend using 'expiry' in combination with 'ignore_content_expiry'. For content that should expire on publish, you can fine tune it with 'subtree_expiry' to make it only expire on specific subtrees. Both of these could and should be combined with 'keys' of course, if you have variables that are used inside the block. eZ Online Editor 5: http://projects.ez.no/ezoe \|\| eZJSCore (Ajax): http://projects.ez.no/ezjscore \|\| eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription @: http://twitter.com/andrerom

Author

Message

Piotrek Karaś

Thursday 19 April 2007 1:00:04 pm

Hello there,

I do realize, that similar questions might have been asked before, but cache issues seems to have been the most troublesome issue of eZ publish, judging by the amount topics the search returns... After some time I just gave up...

The best way I have so far discovered to measure and observe the installation's efficiency when it comes to cache tasks is to display the debug information below the pagelayout and check the amount (or time) of SQL queries. When we clear the entire cache, our sites generate up to 200 of queries (by the way - is that common?), but then each next request only needs just a few (up to 10), depending on which pagelayout parts we decided to leave uncached. It all goes ok until next piece of content is published - no matter where in the content structure menu - it causes the template to require almost the initial amount of queries to be sent again, just before it gets cached again.

I don't expect any detailed info here. Just would like to know if it is a regular eZ publish behavior to expire most of its cache when new content is published? Or is it just my misconfiguration or bad planning?

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

André R.

Friday 20 April 2007 4:05:34 am

Hi!

Take a read on:
http://ez.no/doc/ez_publish/technical_manual/3_8/reference/template_functions/miscellaneous/cache_block

On cache blocks that don't have to expire right away when new content is published I would recommend using 'expiry' in combination with 'ignore_content_expiry'.

For content that should expire on publish, you can fine tune it with 'subtree_expiry' to make it only expire on specific subtrees.

Both of these could and should be combined with 'keys' of course, if you have variables that are used inside the block.

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom