[Seaside] [Seaside-dev] Optimization / performance tuning

Johan Brichau johan at inceptive.be
Mon May 18 07:24:21 UTC 2015

> On 17 May 2015, at 21:54, Phil (list) <pbpublist at gmail.com> wrote:
> On Sun, 2015-05-17 at 13:26 +0200, Johan Brichau wrote:
>> I have never tried anything along those lines but you could decorate a component and keep the rendered html in that decoration. Something along:
>> renderContentOn: html
>> 	^ html html: (generatedHtml ifNil:[ generatedHtml := WAHtmlCanvas builder render:[:html2 | self renderNextOn: html2 ] ])
> That's an interesting idea... I'll give it a shot.

There are probably a lot of caveats in this case. For example, all generated links will refer to the wrong continuation in all but the first rendering pass.
The more I think about what I mentioned, the less I think it’s a good way to approach this, but it depends on what you want to do. I guess the hint about WABuilder is the only thing to remember from my reply :)

>> Though I’m seriously doubting any advantage in performance here by caching. This will only provide an advantage if the rendering code inside that cached component is slow.
>> If you need a page that is cached, try using a restful url in your app and turn on a front-end webserver page cache for that url.
> If I were just looking at performance from the standpoint of a single
> session, I'd agree that it probably wouldn't be worth the effort.

Mind that the decoration solution is on a per-session state basis. So, every session will create its own cache.

> However, with multiple simultaneous sessions/users on a typical
> cycle-starved VPS it is another story.  A front-end cache wouldn't help
> as only part of the page (i.e. the unchanging components) will be static
> across multiple requests.  (Note: the truly static content including css
> and javascript is already being served by Apache)

I think you will want to write a specific component that implements its own cache and fetches the html. In that way, you can share generated html across sessions.
This would this boil down to writing a component that explicitly implements some caching system. Seaside does not know about it and thus mind that the remark about Seaside-generated links still holds: they refer to the session and continuation they are generated in. There are probably other issues, so it greatly depends on what you want to cache.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150518/9956c574/attachment.htm

More information about the seaside mailing list