[Seaside] Seaside cache

[Ramiro Diaz Trepat]

I've posted a comment on Ramon's blog, which triggered a discussion
that I believe has becomed relevant enough to move to the Seaside
list.  So here it is:


Comment from Ramiro Diaz Trepat
Time: February 26, 2007, 2:13 pm

The problem I still see with scaling seaside apps is that you cannot
use a reverse proxy and decide which parts of your web site NOT to
dynamically generate at a certain point.
With seaside you HAVE to generate everything for every request, and
you cannot cache pages because the parameters _s and _k are different
for every session.
Then, for instance, if I have a large catalog of products that rarely
change, and a web page that displays the iniformation for a particular
product, I will always have to dynamically generate this page for a
particular product, It cannot be cached and statically served from a
reverse proxy, even if it got generated 20 times on the last second.
I believe this is a real waste of resources, and makes seaside
applications a lot harder to scale, and probably unsuitable in
practice for real large applications.
May be there is a way around this issue, I don't know. I have asked
about this at least a couple of times on the mailing list but I got no
answer.

____________________________________________________________________________


Comment from Ramon Leon
Time: February 27, 2007, 8:19 am

The _s is different for every session, the _k is different for each
request. Don't get too hung up on that, you can just as easily parse
the state from the url path if needed allowing more restful pages,
Pier does this.

Seaside btw, isn't designed to build mostly static "web" sites, it's
designed to build highly dynamic "applications". Applications
comparable in complexity to desktop applications, where caching has
little if any value. Applications that are so complex that doing them
in another framework isn't really feasible.

Also, that it renders pages dynamically doesn't make Seaside any
harder to scale, it simply makes Seaside require more resources
(hardware) to scale, but if you're serving up so much static or mostly
static content that you're really concerned about caching, then maybe
Seaside isn't the framework you need.


____________________________________________________________________________


Hello Ramón,
May be I did not express myself properly.
By no means I talked about a static web site on my post.  I talk about
caching a dynamic web site which is enormously different.  Most
dynamic web sites can benefit enormously from this, including yours. I
disagree about Seaside being designed for "higly dynamical" web sites
only; where would you put the threshold that divides regular dynamic
web sites from "highly dynamic" web sites.  I think there is no use in
making this categorization.
Not to talk about hypothetical web sites, let's talk about your real
neat travel reservation web site (which I think it's the coolest
Seaside app I've seen so far with DabbleDB),  Is it "highly dynamic"?.
 Don't you have for instance, a catalog of hotels? Imagine your web
site becomes real popular on the next soccer world cup and you have 50
requests per second quering about a specific hotel on a specific town.
 I don't think hotel information changes really often, nevertheless,
you still have to generate it dynamically for each of those 50
requests per second you are serving.
Imagine you could dynamically generate the page for the hotel only
when the underlying object model changed, and all the time in between
the page is served from a cache, at lightning speed and in comparison
without consuming almost any resources.  Wouldn't that produce a MUCH
MUCH better use of your servers? You could probably handle an order of
magnitude or more traffic, and you would not lose anything of your
dynamic functionality.  Just like in all the other frameworks.
So no, I'm not talking about static web sites, nor "less dynamic" web
sites than what Seaside was designed for.

I also think that one of the biggest problems in my beloved Squeak
community is looking the other way when someone points to a problem.
I've seen so many pragmatic and clear problems dragged to a
philosophical ground of discussion about "what is really good", where
any opinion can be relativizied and then dismissed.  For instance,
when a new guy comes and says that Squeak user interface is outdated;
poor dude, then come the philosophical threads about "what is real
good". Who can dare to say that holds the truth? And the problem is
annihilated.
Se we should learn to acknowledge the problems, not to look the other
way with articulated rethoric.
I believe the problem I am pointing out about Seaside's inability to
be proxifyed, is a MAJOR problem, it really sucks. It makes Seaside
applications consume a lot more resources than they should also and be
a lot harder to administrate on a high traffic web site.
I HOPE I AM WRONG, since I really love Seaside.