page caching

> > Hi all - what's the best strategy for caching frequently-requested
> > pages in Seaside? Can you cache raw HTML on a component-by-component
> > basis for performance?
>
> I won't say it can't be done, but it's difficult. The problem is that
> there are no frequently-requested pages in Seaside. Any given url is
> served approximately once, with only backtracking or reloading in the
> browser causing a url to be revisited. Now obviously, many of the
> page-views that Seaside serves will have very similar HTML, but it'll
> never be identical, because the continuation id will be different in
> all the urls in the page.  Maybe there's an opportunity there to come
> up with a system for plugging in those slightly-different bits, but
> nobody has tried it yet, as far as I know.

> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Colin Putney
> Enviado el: Miércoles, 18 de Julio de 2007 21:16
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] page caching
>
>
> On Jul 18, 2007, at 2:14 PM, Giles Bowkett wrote:
>
> > Hi all - what's the best strategy for caching frequently-requested
> > pages in Seaside? Can you cache raw HTML on a
> component-by-component
> > basis for performance?
>
> I won't say it can't be done, but it's difficult. The problem
> is that there are no frequently-requested pages in Seaside.
> Any given url is served approximately once, with only
> backtracking or reloading in the browser causing a url to be
> revisited. Now obviously, many of the page-views that Seaside
> serves will have very similar HTML, but it'll never be
> identical, because the continuation id will be different in
> all the urls in the page.  Maybe there's an opportunity there
> to come up with a system for plugging in those
> slightly-different bits, but nobody has tried it yet, as far
> as I know.
>
> Colin
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I'm also wont say is not possible. But yes, cache hits will be kind of
> complex for Seaside. To compare think about caching the views in a desktop
> application. The OS creates and destroys views all the time. For it caching
> widgets (it's not it's bottleneck anyway) will be complex not to mention
> it's state (which the continuations solves). Getting a nice cache solution
> for Seaside will be quite challenging mostly because the cache policy will
> strongly depend on your own application.
>
>         cheers,
>
> Sebastian Sastre
>
>  > -----Mensaje original-----
> > De: [hidden email]
> > [mailto:[hidden email]] En nombre
> > de Colin Putney
> > Enviado el: Miércoles, 18 de Julio de 2007 21:16
> > Para: Seaside - general discussion
> > Asunto: Re: [Seaside] page caching
> >
> >
> > On Jul 18, 2007, at 2:14 PM, Giles Bowkett wrote:
> >
> > > Hi all - what's the best strategy for caching frequently-requested
> > > pages in Seaside? Can you cache raw HTML on a
> > component-by-component
> > > basis for performance?
> >
> > I won't say it can't be done, but it's difficult. The problem
> > is that there are no frequently-requested pages in Seaside.
> > Any given url is served approximately once, with only
> > backtracking or reloading in the browser causing a url to be
> > revisited. Now obviously, many of the page-views that Seaside
> > serves will have very similar HTML, but it'll never be
> > identical, because the continuation id will be different in
> > all the urls in the page.  Maybe there's an opportunity there
> > to come up with a system for plugging in those
> > slightly-different bits, but nobody has tried it yet, as far
> > as I know.
> >
> > Colin
> > _______________________________________________
> > 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
>

> Caching would be a real nice thing to have in Seaside.  I believe in
> the feature it would be great if Seaside would not be as closed to
> this completely dynamic model and some ordinary RESTful urls could be
> added to your application, it could come in very handy.  But for now,
> I think is almost impossible to do any page caching.
> It is a shame since in any large web site there are probably lots of
> sections that change seldom and that are identical for all users,
> saying that Seaside should not be used in those cases is also not a
> good answer for me.
> The good news is that probably a big bottleneck on web apps is the
> access to the database, more than the Seaside HTML generation.  So if
> you want to cache those, it could be a good idea.  I was thinking on
> implementing the Squeak client for memcached, and using it to cache
> and distribute persistent data across multiple images / servers.

> IMO, page caching is more relevant when you are doing static
> translations from one format to another.  For example, if you have a
> site that stores everything in some XML format, and you want to use
> XSLT or something to translate it to HTML.  That would be a great
> candidate for caching since the translation is expensive and returns
> the same results every time for a given source document.
>
> But most Seaside apps are views of real/live objects.  So to cache
> that would amount to creating a string of all the objects instance
> variable values for your hash key (e.g. an MD5 string).  Something
> like that could done automatically with a clever enough frame work,
> but the question is: would it be worth it to create such machinery?  
> Has anyone actually hit a render bottleneck yet?  Last I heard the
> encoding and socket writing was taking up all the time.