Presentation layer cache - Newscoop Development Discussions on Sourcefabric Forum

Andrey Podshivalov

hi,

id like to introduce my vision about campsite cache.

As you know the Campsite support db layer caching. The first cache adapter was APC. It allows to cache sql queries results in a memory. It decrease site response about 2x. Looks good but we have some principal problems. 1. APC is not enabled on shared hosting. 2. APC is unstable on Virtual Servers which based on linux containers (like openvz/virtuozzo, lxc). 3. DB layer caching requires very punctual db queries programming. Unfortunately, new introduced functionality brings new db cache issues (unimplemented cache clear triggers) or/and new uncached queries.
To resolve first two problem I've implemented file based adapter but this solution can not be used: cache size can grow more than 20Mb. In this case the file cache decelerates the site response.

So, I'm thinking about presentation layer caching that based on file system. It resolves all principal db layer cache problems but there is another presentation layer specific problem: the rendered page has different logic blocks with different cache lifetime requirements (e.g. article, polls, comments, informers).
I'm going to resolve it via small template refactoring:
1. Each logic content block should be moved into separate template file.
2. The template file can contain cache specific header with lifetime information.

The file system organization will replicate campsite content structure: publication/lang/issue/section/article

Case scenario: author has changed article #2354 in section # 12, issue #109 After then cache manager is cleaning up 3 folders for issue 109, section 12 and article 2354 (109, 109/12 and 109/12/2354). It looks simple to implement.

Also I'd like to cache the images from getimage output.

That's main idea. Suggestions, ideas, criticism absolutely welcome.

Holman Romero

Hi Andrey,

Do not forget Smarty caching capability. It is file-based and
implements a good level of flexibility, you can set selective template
caching where you would say "hey article.tpl template is gonna be
cached and re-created once a day and home.tpl is not gonna be cached
at all" or even you could say "blocks for main news and headlines in
home.tpl are gonna be cached and re-created every 1 hour, while blocks
for latest comments and twitts also in home.tpl won't be cached at
all".

How to handle and control this behavior from Campsite is the question
as it is up to the templates developer in the first case.

On Fri, Sep 10, 2010 at 11:55 AM, Andrey Podshivalov
<campsite-dev@lists.sourcefabric.org> wrote:
>
> hi,
>
> id like to introduce my vision about campsite cache.
>
> As you know the Campsite support db layer caching. The first cache adapter was APC. It allows to cache sql queries results in a memory. It decrease site response about 2x. Looks good but we have some principal problems. 1. APC is not enabled on shared hosting. 2. APC is unstable on Virtual Servers which based on linux containers (like openvz/virtuozzo, lxc). 3. DB layer caching requires very punctual db queries programming. Unfortunately, new introduced functionality brings new db cache issues (unimplemented cache clear triggers) or/and new uncached queries.
> To resolve first two problem I've implemented file based adapter but this solution can not be used: cache size can grow more than 20Mb. In this case the file cache decelerates the site response.
>
> So, I'm thinking about presentation layer caching that based on file system. It resolves all principal db layer cache problems but there is another presentation layer specific problem: the rendered page has different logic blocks with different cache lifetime requirements (e.g. article, polls, comments, informers).
> I'm going to resolve it via small template refactoring:
> 1. Each logic content block should be moved into separate template file.
> 2. The template file can contain cache specific header with lifetime information.
>
> The file system organization will replicate campsite content structure: publication/lang/issue/section/article
>
> Case scenario: author has changed article #2354 in section # 12, issue #109 After then cache manager is cleaning up 3 folders for issue 109, section 12 and article 2354 (109, 109/12 and 109/12/2354). It looks simple to implement.
>
> Also I'd like to cache the images from getimage output.
>
> That's main idea. Suggestions, ideas, criticism absolutely welcome.
>

--
Holman Romero
Senior Software Engineer, Sourcefabric
holman.romero@sourcefabric.org

Salvátorská 10
110 00 Praha 1, Czech Republic
+420 607 133 896

http://www.sourcefabric.org

Andrey Podshivalov

Holman Romero wrote on Fri, 10 September 2010 18:02

How to handle and control this behavior from Campsite is the question
as it is up to the templates developer in the first case.

I'm thinking about Template manger. In additional to template editing we can add cache lifetime property for each template. After saving template the Template manager refreshes template cache lifetime settings document for Smarty lib.

Douglas Arellanes

For what it's worth, the NYTimes uses Varnish, and they wrote this blog entry about it on their developer blog: http://open.blogs.nytimes.com/2010/09/15/using-varnish-so-ne ws-doesnt-break-your-server/

Paul Baranowski

I would agree with this - we dont really want to invent our own caching
system. There are tons of caching systems already built, we should use one
of them. What is preventing us from doing that? What are the scenarios
that we need to refresh different parts of the page at different intervals
(i.e. why not just set a global timeout of 1-5 min or so)? And what about
serving code to the client so that it fetches different content instead of
doing it server side? Andrey - you mention that "20MB" of cache is too
big. Is that number correct, because that seems like a very small number
for a cache? What does it mean to be "too big"? And is that in RAM or on
the file system? No matter which one, it seems like a very small number for
a cache. (e.g. the Java interpreter uses more space than that in memory).

Paul Baranowski
Chief Technology Officer, Sourcefabric

paul.baranowski@sourcefabric.org
+1 (416) 619-0874 (Office)
+1 (416) 832-6436 (Cell)
Toronto, ON, Canada

http://sourcefabric.org
Skype: paulbaranowski

On Wed, Sep 15, 2010 at 9:56 AM, Douglas Arellanes <
campsite-dev@lists.sourcefabric.org> wrote:

> For what it's worth, the NYTimes uses Varnish, and they wrote this blog
> entry about it on their developer blog: http://open.blogs.nytimes.com/2010/09/15/using-varnish-so-ne
> ws-doesnt-break-your-server/< http://open.blogs.nytimes.com/2010/09/15/using-varnish-so-ne ws-doesnt-break-your-server/>
>

Mugur Rus

"1. APC is not enabled on shared hosting. 2. APC is unstable on Virtual
Servers which based on linux containers (like openvz/virtuozzo, lxc)."
Writing a Campsite driver for another PHP cache engine (xcache, eaccelerator
etc.) is a *1 hour* time work. Isn't any of these engines available on
shared hosting?

"Unfortunately, new introduced functionality brings new db cache issues
(unimplemented cache clear triggers) or/and new uncached queries."
Data access caching is transparent, for any new table in the db structure
you just need to inherit from DatabaseObject. There are indeed other data
structures like lists of objects that need manual refreshing on data change
but from now on Campsite is kind of in just maintenance mode, it's not worth
putting too much work in it.

"1. Each logic content block should be moved into separate template file."
You can't force web designers to do this kind of structuring, I'm sure we
would hear cries of madness.

"2. The template file can contain cache specific header with lifetime
information."
Don't forget that each template is used for serving multiple pages. E.g.:
section.tpl displays any section based on parameters so you would have to
set the cache specific header based on URL, not template file.

"The file system organization will replicate campsite content structure:
publication/lang/issue/section/article"
Again, cries of madness from web-designers. Plus, what do you do with blocks
that are common to all pages?

Anyway, as Paul said, I don't see the point in putting our resources to
build a custom cache instead of using existing solutions.

Mugur Rus
Senior Software Developer, Sourcefabric
mugur.rus@sourcefabric.org

Cluj-Napoca, Romania
+40 (0)720 528408
Skype: mugur_rus

http://www.sourcefabric.org
http://www.twitter.com/Sourcefabric

On Fri, Sep 10, 2010 at 12:55 PM, Andrey Podshivalov <
campsite-dev@lists.sourcefabric.org> wrote:

> hi,
>
> id like to introduce my vision about campsite cache.
>
> As you know the Campsite support db layer caching. The first cache adapter
> was APC. It allows to cache sql queries results in a memory. It decrease
> site response about 2x. Looks good but we have some principal problems. 1.
> APC is not enabled on shared hosting. 2. APC is unstable on Virtual Servers
> which based on linux containers (like openvz/virtuozzo, lxc). 3. DB layer
> caching requires very punctual db queries programming. Unfortunately, new
> introduced functionality brings new db cache issues (unimplemented cache
> clear triggers) or/and new uncached queries.
> To resolve first two problem I've implemented file based adapter but this
> solution can not be used: cache size can grow more than 20Mb. In this case
> the file cache decelerates the site response.
>
> So, I'm thinking about presentation layer caching that based on file
> system. It resolves all principal db layer cache problems but there is
> another presentation layer specific problem: the rendered page has different
> logic blocks with different cache lifetime requirements (e.g. article,
> polls, comments, informers).
> I'm going to resolve it via small template refactoring:
> 1. Each logic content block should be moved into separate template file.
> 2. The template file can contain cache specific header with lifetime
> information.
>
> The file system organization will replicate campsite content structure:
> publication/lang/issue/ section/article
>
> Case scenario: author has changed article #2354 in section # 12, issue #109
> After then cache manager is cleaning up 3 folders for issue 109, section 12
> and article 2354 (109, 109/12 and 109/12/2354). It looks simple to
> implement.
>
> Also I'd like to cache the images from getimage output.
>
> That's main idea. Suggestions, ideas, criticism absolutely welcome.
>
>

Andrey Podshivalov

Paul Baranowski wrote on Thu, 16 September 2010 00:34

I would agree with this - we dont really want to invent our own caching
system. There are tons of caching systems already built, we should use one
of them.

Do you mean an external cache system like Varnish? Then this systems isn't accessible on shared hosting and it doesn't resolve the problem on dedicated. I'm using for more than 10 sites the Squid as site accelerator (I've tested both Varnish and Squid but Squid looks more stable) with cache lifetime 10 mins. It works fine for human visitors who views usually the same latest content but doesn't for search/spam crawlers which retrieves any content. In addition I have to migrate sites on shared hosting where apc or any site accelerators are missing.

Quote:

What is preventing us from doing that? What are the scenarios
that we need to refresh different parts of the page at different intervals
(i.e. why not just set a global timeout of 1-5 min or so)? And what about
serving code to the client so that it fetches different content instead of
doing it server side?

About global timeout. As I said it doesn't help for search crowlers and there is another problem - authors would like to see the modifications on the frontend w/o waiting. With Squid the author has to press Shift+Reload (just Reload isn't working) to tell Squid to fresh cache.

Quote:

Andrey - you mention that "20MB" of cache is too
big. Is that number correct, because that seems like a very small number
for a cache? What does it mean to be "too big"? And is that in RAM or on
the file system?

It's a file-based cache adapter.

Quote:

No matter which one, it seems like a very small number for
a cache. (e.g. the Java interpreter uses more space than that in memory).

It matters for php. The cache file should be included in each request. I've tested different formats the best result if cache is presented as raw php array in one file. Unserialization takes after 10 mb more than 1 sec. The same situationin in case separation of each db query result into different file (campsite generates 700-1500 db queries per page request)

So php format looks the faster but php is interpreter and that 20MB should be interpreted on each request (opcode doesn't help - file is not statical).
The best results I've got on file less than 10 mb.

Any other solutions like any db library (sqlite, berkleydb) or mysql as storage container doesn't look interesting for me because as I said APC speeds up about x2 but I need more than APC allows.

Andrey Podshivalov

Mugur Rus wrote on Thu, 16 September 2010 10:22

"1. APC is not enabled on shared hosting. 2. APC is unstable on Virtual
Servers which based on linux containers (like openvz/virtuozzo, lxc)."
Writing a Campsite driver for another PHP cache engine (xcache, eaccelerator
etc.) is a *1 hour* time work. Isn't any of these engines available on
shared hosting?

You should understand the differences between opcode caching and data caching. Each shared hosting has some opcode cacher (apc, zend etc) but with disabled data caching

Quote:

"Unfortunately, new introduced functionality brings new db cache issues
(unimplemented cache clear triggers) or/and new uncached queries."
Data access caching is transparent, for any new table in the db structure
you just need to inherit from DatabaseObject. There are indeed other data
structures like lists of objects that need manual refreshing on data change
but from now on Campsite is kind of in just maintenance mode, it's not worth
putting too much work in it.

Mugur, just test the latest version and you will be surprised that about 10% queries are missed in the cache on each same request.

Quote:

Anyway, as Paul said, I don't see the point in putting our resources to
build a custom cache instead of using existing solutions.

Guys, I'm waiting for constructive suggestions. As I said I'm using the Squid but I'm not happy how Campsite loads the server anyway. I don't see any other solution except campsite specific cache implementation.

Jacob

Really I am 100% with Andrey
use MYsql for Cache is load your server and use memory you not need. also the server become expensive because you need more ram

About I read before 20 megas memory. ????? How use 20 megas memory for cache. If is impossible

Mysql is never a good option for cache

Mugur Rus

"You should understand the differences between opcode caching and data
caching. Each shared hosting has some opcode cacher (apc, zend etc) but with
disabled data caching"
Andrey, you were talking about the db layer caching, here are your words: "As
you know the Campsite support db layer caching." Also, you mentioned APC was
disabled on shared hosting, *not* data caching: "1. APC is not enabled on
shared hosting". That's why I asked whether other data caching engines were
enabled.

You did not talk about opcode caching and my answer also implied data
caching.

Publications that have high traffic and need data caching should not use
crappy shared hosting. Period. As I remember CPP sites use APC data cache
and they are on shared hosting.

"Mugur, just test the latest version and you will be surprised that about
10% queries are missed in the cache on each same request."
Will check that.

Mugur Rus
Senior Software Developer, Sourcefabric
mugur.rus@sourcefabric.org

Cluj-Napoca, Romania
+40 (0)720 528408
Skype: mugur_rus

http://www.sourcefabric.org
http://www.twitter.com/Sourcefabric

On Thu, Sep 16, 2010 at 10:41 AM, Andrey Podshivalov <
campsite-dev@lists.sourcefabric.org> wrote:

> Mugur Rus wrote on Thu, 16 September 2010 10:22
>
> "1. APC is not enabled on shared hosting. 2. APC is unstable on Virtual
> Servers which based on linux containers (like openvz/virtuozzo, lxc)."
> Writing a Campsite driver for another PHP cache engine (xcache,
> eaccelerator
> etc.) is a *1 hour* time work. Isn't any of these engines available on
> shared hosting?
>
>
>
> You should understand the differences between opcode caching and data
> caching. Each shared hosting has some opcode cacher (apc, zend etc) but with
> disabled data caching
>
> Quote:
>
>
> "Unfortunately, new introduced functionality brings new db cache issues
> (unimplemented cache clear triggers) or/and new uncached queries."
> Data access caching is transparent, for any new table in the db structure
> you just need to inherit from DatabaseObject. There are indeed other data
> structures like lists of objects that need manual refreshing on data change
> but from now on Campsite is kind of in just maintenance mode, it's not
> worth
> putting too much work in it.
>
>
> Mugur, just test the latest version and you will be surprised that about
> 10% queries are missed in the cache on each same request.
>
> Quote:
>
>
> Anyway, as Paul said, I don't see the point in putting our resources to
> build a custom cache instead of using existing solutions.
>
>
>
> Guys, I'm waiting for constructive suggestions. As I said I'm using the
> Squid but I'm not happy how Campsite loads the server anyway. I don't see
> any other solution except campsite specific cache implementation.
>
>

Andrey Podshivalov

Mugur Rus wrote on Thu, 16 September 2010 12:26

Publications that have high traffic and need data caching should not use
crappy shared hosting. Period. As I remember CPP sites use APC data cache
and they are on shared hosting.

Several sites are running on VPS where I can not use APC data cache - It's too unstable. Other sites are working on shared hosting w/o enabled APC data caching.

Paul Baranowski

Hi Andrey-
How about "memcached" - any reason this wouldnt work?

Paul Baranowski
Chief Technology Officer, Sourcefabric

paul.baranowski@sourcefabric.org
+1 (416) 832-6436 (Cell)
Toronto, ON, Canada

http://sourcefabric.org
Skype: paulbaranowski

On Thu, Sep 16, 2010 at 6:41 AM, Andrey Podshivalov <
campsite-dev@lists.sourcefabric.org> wrote:

> Mugur Rus wrote on Thu, 16 September 2010 12:26
>
>
> Publications that have high traffic and need data caching should not use
> crappy shared hosting. Period. As I remember CPP sites use APC data cache
> and they are on shared hosting.
>
>
> Several sites are running on VPS where I can not use APC data cache - It's
> too unstable. Other sites are working on shared hosting w/o enabled APC data
> caching.
>

Andrey Podshivalov

hi Paul,

memcacached on vps doesn't resolve APC issue. The problem is memory management on the linux containers like Virtuozzo/OpenVZ or LXC. The containers tells to programs there is enough free memory but the program can not allocate and generates segfault. It's vps specific problem, not APC. Also on shared hosting the memcached isn't available usually.

Btw, I've implemented the template caching and now is testing on several production sites. Looks very promised: the template caching accelerates site response about 5x-12x. It depends on how many code in a template has been excluded from caching. I'll announce more details a bit later.

Andrey Podshivalov

Finally the template cache has been implemented and tested.
I'd like to explain how template caching works.

To exclude dynamic stuff I've added {{ dynamic }} block. Any code inside dynamic block will be excluded form cache and rendered on each request.

It was first version of template cache handler. It had been working fine but without so many dynamic excluded parts. For given example the cache accelerates just about 2x times than uncached.

That's not fine for me. I'd like more Smile

and I've implemented the second template cache handler version with multirendering support. It allows to render included sub-templates by separate rendering process with personal cache settings. The next version contains new function {{ render }}

Full specification:
{{ render file="template_name" [issue=off|issueid] [section=off|sectionid] [article=off|articleid] [params=paremeters] [cache=secs] }}

where

file: template filename
issue: to cache for any issue or for an issue with issueid
section: to cache for any section or for a section with sectionid
article: to cache for any article or for a article with articleid
params: specify additional parameters
cache: overwrite the cache settings in template manager

Let's see on example.
Here is the layout of standard section page.
index.php/fa/35/0/

We need to exclude from caching some dynamic stuff:
1. Most popular list
2. Most commented list
3. External informers
4. Template contains article list pagination.

Let's define some parameters for dynamic stuff:
Most popular article list is defined for issue only.
Most commented article list is defined for all articles in any issue
Informers should be included on each request
Pagination generates links like http://site/en/pub/issue/section/?page=n

Most popular and commented lists should be cached for 600 sec
The main template section.tpl should be cached for 30 days

Let's do it.

The cache lifetime for main template can be defined in Template manager:
index.php/fa/36/0/

Most popular list:
{{ render file="most_popular.tpl" section=off cache=600 }}

Most commented list:
{{ render file="most_commented.tpl" issue=off section=off cache=600 }}

Informers:
{{ dynamic }}
{{ php }} inclide 'informer1.php'; {{ php }}
{{ /dynamic }}

Section article list with pagination:
{{ render file="section_list.tpl" params=$campsite->url->get_parameter(page) }}

On article changing or issue publishing/unpublishing the cache manager cleans outdated cached template. Cleaning algorithm based on campsite specific parameters: language, publication, issue, section, article, template, additional params.

Some testing results (site response):
belmarket.by - shared hosting/
Rendering time w/o caching: 3200 ms
Rendering time w/ caching: 200 ms (11x)

newsabah.com - vps
Rendering time w/o caching: 300 ms
Rendering time w/ caching: 35 ms (8,5x)

nv-online.info - vps
Rendering time w/o caching: 2100 ms
Rendering time w/ caching: 40 ms (50x!!!)

well, I'm happy now Smile

Sava Tatić

Congratulations, Andrey.

So this is already committed into the 3.5 branch? Will users have to wait for
it to take advantage of it?

All the best,

Sava

On Friday, October 08, 2010 16:13:14 Andrey Podshivalov wrote:
> Finally the template cache has been implemented and tested.
> I'd like to explain how template caching works.
>
> To exclude dynamic stuff I've added {{ dynamic }} block. Any code inside
> dynamic block will be excluded form cache and rendered on each request.
>
> It was first version of template cache handler. It had been working fine
> but without so many dynamic excluded parts. For given example the cache
> accelerates just about 2x times than uncached.
>
> That's not fine for me. I'd like more and I've implemented the second
> template cache handler version with multirendering support. It allows to
> render included sub-templates by separate rendering process with personal
> cache settings. The next version contains new function {{ render }}
>
> Full specification:
> {{ render file="template_name" [issue=off|issueid] [section=off|sectionid]
> [article=off|articleid] [params=paremeters] [cache=secs] }}
>
> where
>
> file: template filename
> issue: to cache for any issue or for an issue with issueid
> section: to cache for any section or for a section with sectionid
> article: to cache for any article or for a article with articleid
> params: specify additional parameters
> cache: overwrite the cache settings in template manager
>
> Let's see on example.
> Here is the layout of standard section page.
>
>
> We need to exclude from caching some dynamic stuff:
> 1. Most popular list
> 2. Most commented list
> 3. External informers
> 4. Template contains article list pagination.
>
> Let's define some parameters for dynamic stuff:
> Most popular article list is defined for issue only.
> Most commented article list is defined for all articles in any issue
> Informers should be included on each request
> Pagination generates links like http://site/en/pub/issue/section/?page=n
>
> Most popular and commented lists should be cached for 600 sec
> The main template section.tpl should be cached for 30 days
>
> Let's do it.
>
> The cache lifetime for main template can be defined in Template manager:
>
> Most popular list:
> {{ render file="most_popular.tpl" section=off cache=600 }}
>
> Most commented list:
> {{ render file="most_commented.tpl" issue=off section=off cache=600 }}
>
> Informers:
> {{ dynamic }}
> {{ php }} inclide 'informer1.php'; {{ php }}
> {{ /dynamic }}
>
> Section article list with pagination:
> {{ render file="section_list.tpl"
> params=$campsite->url->get_parameter(page) }}
>
> On article changing or issue publishing/unpublishing the cache manager
> cleans outdated cached template. Cleaning algorithm based on campsite
> specific parameters: language, publication, issue, section, article,
> template, additional params.
>
> Some testing results (site response):
> belmarket.by - shared hosting/
> Rendering time w/o caching: 3200 ms
> Rendering time w/ caching: 200 ms (11x)
>
> newsabah.com - vps
> Rendering time w/o caching: 300 ms
> Rendering time w/ caching: 35 ms (8,5x)
>
> nv-online.info - vps
> Rendering time w/o caching: 2100 ms
> Rendering time w/ caching: 40 ms (50x!!!)
>
> well, I'm happy now
>
>
> To participate in the discussion, go here:
> http://forum.sourcefabric.org/index.php?t=rview&frm_id=1 1

--
Sava Tatić
Managing Director, Sourcefabric o.p.s.
sava.tatic@sourcefabric.org

Salvátorská 10
110 00 Praha 1, Czech Republic
+420222362540
+420602653104 (mobile)
Skype: tictactatic

http://www.sourcefabric.org
http://www.twitter.com/Sourcefabric

Andrey Podshivalov

yes, it's in the repository already and will be available in 3.5 release

Douglas Arellanes

And would this be interesting for upstream Smarty developers, or is it specific to Campsite ?

Andrey Podshivalov

Just for campsite. There isn't any smarty trick.

Howdy, Stranger!

Categories

Poll

Top Posters