[Seaside] page caching
Jason Johnson
jbjohns at libsource.com
Thu Jul 19 15:27:58 UTC 2007
Ramiro Diaz Trepat wrote:
> 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.
More information about the Seaside
mailing list