We are experiencing some performance issues on a fairly large Silverstripe site and I'm trying to 'fix' it by using APC (a PHP cacher).
- We have quite some dynamic pages (logins etc.) , so can't use the static exporter.
- I've tried to store collections of Silverstripe objects (mainly DataObjectSets) in APC , but trying to get them to serialize and unserialize turned out to be a b*tch.
- Storing parts of pages is hard, since I don't really know where to start .... It would be great to tie a caching mechanism into the Silverstripe template system itself ....
AFAIK, you can limit StaticPublisher to certain pages, and serve others dynamically. This of course assumes you don't have dynamic parts like a "logged in as" on all pages. What problems did you have with caching DataObjects? Did they not properly "re-hydrate"?
Caching on a template level would probably be the best "bang for your buck", but is also the hardest to invalidate, which is why SilverStripe has traditionally stayed away from this. Thats not to say its impossible though... Sorry can't help more at the moment, let us know how you get on!
>> [EDIT] But nah... I guess adding HTML from the controller is something of a last resort.
Trust me , it was. ;-)
>>Does it really make much of a difference though? As in time?
Well, the site I was trying to speed up contains a LOT of custom work (pulling data from different webservices etc. etc.) that involved a lot of (expensive) casting to and from silverstripe data-objects (in order to use them "nicely" in the template)... So yes, caching the HTML shaved off a lot of processing time! ;)
Still there's something to say for extending static publishing. For instance - I had this site that had a 'static sidebar' - some data that appear throughout the site, but would often be changed by the client (like adding an extra link or so) In this case it was an extra ssbits-style sidebar that was in fact a page in the CMS. Problem: whenever the sidebar is changed, all static pages on the site have to be updated - something you don't really want.
It would be great to have a way you could dynamically combine two or more static files - just thinking out loud: one way would be have HTML generated differently for the StaticPublisher by acknowledging a special command in the template that tells the templating engine to replace a certain block of code by an include statement. Maybe by just calling the page in a /dev/static/ kind of way from the publisher? So now you'd have a somewhat less static' file with an include to another static file? This file could then be interpreted by a script that combines the lot.
You could even have the script simply replace a block of html based on a comment in the template and leave out the StaticPublisher changes for now. I'm a bit worried about security though...
And of course, as you're importing all kinds of dynamic external content, this has no use whatsoever... But still...