5416 Posts in 1652 Topics by 1188 members
|Go to End|
22 September 2009 at 12:24am
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 ....
Did anyone succeed in doing something like this ?
Pointers / ideas are of course also welcome. ;-)
27 September 2009 at 4:46pm
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!
28 September 2009 at 8:29pm
Thanks for your reply.
> This of course assumes you don't have dynamic parts like a "logged in as" on all pages.
Indeed, we do have a "login" part on each and every page. No go for the static publisher.
> What problems did you have with caching DataObjects? Did they not properly "re-hydrate"?
Yup. Did not find a working method to serialize and deserialize them ....
8 October 2009 at 3:53am
Did you get any further with this?
As for template caching, would that be something like <% cache %> cache this <% end_cache %>? That would be a totally different system from the static publisher...
Just wondering what percentage of time goes into the actual rendering of the template? So how much would, say, caching an entire page except for a simple form reduce loading time?
8 October 2009 at 4:05am
Nope. I ended up creating some very nasty hacks that involved generating and outputting HTML in my controller classes so I could properly cache them.... Hehe...
The rendering of the template isn't that big of a deal. I just want to prevent running the controller code if not needed (ergo , when a cached version exists).
8 October 2009 at 4:55am Last edited: 8 October 2009 5:29am
>> I ended up creating some very nasty hacks...
I would be interested I have my share of slooowhosts
I've not gone much farther yet then having my static forms php-validate dynamically, by adding some thingy to the url...
[EDIT] But nah... I guess adding HTML from the controller is something of a last resort. Does it really make much of a difference though? As in time?
8 October 2009 at 7:50am
>> [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! ;)
8 October 2009 at 9:52pm
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...
|Go to Top|