Smalltalk › Frameworks & Tools › Seaside › Seaside General

Re: [Seaside-dev] Optimization / performance tuning

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Johan Brichau-2

Re: [Seaside-dev] Optimization / performance tuning

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 ] ])

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.

Disclaimer: I also don’t know if the above really works and what caveats might arise. Keep us posted if you give it a try.

Johan

> On 17 May 2015, at 03:32, Phil (list) <[hidden email]> wrote:
>
> While the actual implementation would likely be application specific, I
> was wondering if there are any facilities in Seaside to help optimize
> Seaside application performance? For example, given an invariant
> component branch, is there any way to render once at the instance or
> session level and cache the resulting output rather than re-rendering
> each time the page is loaded? Any pointers to tips and techniques along
> these lines would be appreciated...
>
> Thanks,
> Phil
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Phil B

Re: [Seaside-dev] Optimization / performance tuning

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.

> 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.
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)

> Disclaimer: I also don’t know if the above really works and what caveats might arise. Keep us posted if you give it a try.
>
> Johan
>
> > On 17 May 2015, at 03:32, Phil (list) <[hidden email]> wrote:
> >
> > While the actual implementation would likely be application specific, I
> > was wondering if there are any facilities in Seaside to help optimize
> > Seaside application performance? For example, given an invariant
> > component branch, is there any way to render once at the instance or
> > session level and cache the resulting output rather than re-rendering
> > each time the page is loaded? Any pointers to tips and techniques along
> > these lines would be appreciated...
> >
> > Thanks,
> > Phil
> >
> > _______________________________________________
> > seaside-dev mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Johan Brichau-2

Re: [Seaside-dev] Optimization / performance tuning

On 17 May 2015, at 21:54, Phil (list) <[hidden email]> 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.

Johan

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Philippe Marschall

Re: [Seaside-dev] Optimization / performance tuning

On Mon, May 18, 2015 at 9:24 AM, Johan Brichau <[hidden email]> wrote:

>
> On 17 May 2015, at 21:54, Phil (list) <[hidden email]> 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 :)

Right, in general you should not use #callback if you intend to cache
the result.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside