Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Caching strategy for largely static site with small amount of dynamic content on some pages.


Reply


5 Posts   763 Views

Avatar
vwd

Community Member, 160 Posts

12 May 2012 at 12:44am

Edited: 12/05/2012 12:46am

Hi,

What caching strategy would you recommendation for a largely static site which has some dynamic content (eg. a photo feed from another server) on some of the pages?

I would imagine that I would use Static Publisher for all static pages, and then partially cache the pages with the partial dynamic content. Am I correct?

But what I'm particularly curious about is how to use partial caching when a page is largely static but contains only a small amount of dynamic content. Would I put a partial cache block around most of the rest of template with no key (ie so it re-caches after the default TTL) and then cache block with appropriate keys around the dynamic portions of the template? I don't see any examples where it is done like this. For example, usually the majority of a page is static (eg. head, navigation bar, footer) - it seems strange to have to insert partial cache blocks around all these parts of the template. So how would we go about caching the majority of the page, and then using the partial cache blocks with appropriate keys for the dynamic portions? I'd imagine this is a fairly common issue?

<html>
<head>
<% include HeadDetails %>
</head>
<body>
<div id="container">
<% include Header %>
<% include NavBar %>

$Content
$Form

<%-- I want the PhotoFeedFromFlickr template portion to be re-cached only if a new photo is in the stream, but otherwise, the rest of the page should be cached always for the default TTL --%>
<% cached LatestPhotoDataInFlickrStream %>
<% include PhotoFeedFromFlickr %>
<% end_cached %>

<% include Footer %>
</div>
</body>
</html>

Looking forward to hearing what you have to say.

Thanks.
VWD.

Avatar
Willr

Forum Moderator, 5513 Posts

13 May 2012 at 6:14pm

You don't need to bother wrapping any caching around static html areas (such as footer html) as that just increases the size of your cache without any major benefit. I'd suggest just find everywhere that is dynamic and partial cache those individual sections.

<% cached 'navigation' %>
..
<% end_cached %>
..
<% cached 'pagecontent', LastEdited %>
..
<% end_cached %>

Things like $Form you don't want to cache anyway.

Avatar
vwd

Community Member, 160 Posts

15 May 2012 at 10:40am

Thanks Will. I think you've helped me to understand a little better how SS caching works.

So there isn't much advantage in caching any of the <% include %> blocks that are largely static?

For example, my templates are broken up into smaller blocks eg. Nav, Head, Header, Footer as per code example below. Assembling these to serve up a page would cost some processing time I'd imagine. Caching these doesn't save much processing time, by helping to pre-assemble the smaller blocks to a full template?

Thanks Will.

VWD.

Avatar
Willr

Forum Moderator, 5513 Posts

15 May 2012 at 11:36am

For example, my templates are broken up into smaller blocks eg. Nav, Head, Header, Footer as per code example below. Assembling these to serve up a page would cost some processing time I'd imagine. Caching these doesn't save much processing time, by helping to pre-assemble the smaller blocks to a full template?

Correct, caching those is not going to improve performance greatly as SS already 'caches' includes and generally templates (thats why you need to use ?flush=1 when making changes).

Key is just to wrap anywhere that hits the database or other code which takes up processing time.

Avatar
vwd

Community Member, 160 Posts

15 May 2012 at 1:03pm

Thanks very much for clearing that up Will. I understand now.

I really have to dig a little deeper then to investigate an intermittent performance issue with a site.

Thanks.
VWD.