[Seaside] Seaside cache
boris at deepcovelabs.com
Wed Feb 28 15:51:28 UTC 2007
Back to original question for a second. I can't help but wonder how would you rely on front webserver caching your pages when they have information specific to the user anyway. Most likely somewhere you have login/logout button that depends on specific session state and users name included somewhere on the page, nevermind user-specific content like their favourite destinations list etc. I just can't imagine a hotel description page that is completely separated from all of that. And if it is, how about saving it to disk and letting front web server do its magic then?
(Sent from a BlackBerry)
----- Original Message -----
From: seaside-bounces at lists.squeakfoundation.org <seaside-bounces at lists.squeakfoundation.org>
To: 'The Squeak Enterprise Aubergines Server - general discussion.' <seaside at lists.squeakfoundation.org>
Sent: Wed Feb 28 07:41:02 2007
Subject: RE: [Seaside] Seaside cache
> 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.
I'm not disagreeing that the ability to cache the site wouldn't be nice.
Certainly it would, but it's a very complicated issue because Seaside relies
so heavily on Sessions to enable all the magic that makes working in it so
Those pages have so many Ajax callbacks in them that assume there is state
sitting on the server waiting to answer them. Were a page somehow served
from a cache, the server side session would eventually expire, the state
would disappear, and the cached page would no longer work. The cache is
also user specific, so without some kind of major core rewrite of the one
thing that makes Seaside different, and a joy to work with, Sessions, I just
don't see how such a page can be cached.
I do have caching in the site, but I do it at the db call level, rather than
at the page level. To make a cache work, you'd have to make the calls
stateless, encoding the necessary state information into the URL directly
and re-fetching the objects per request, and running stateless with data
encoded into the URL is everything Seaside tries to avoid.
I could be totally wrong, maybe someone smarter than me will come along and
see an elegant way to do it without losing that Seaside feel, but I just
don't see how it'd work. Of course, I'd not complain at all if someone
figured out how to do it. ;)
At the moment, my time costs far more than web servers do, so I'm happy to
throw hardware at the problem to make it scale and serve up everything
dynamically. As far as I'm concerned, it's a small price to pay for the joy
of programming in Seaside.
I would of course, love to see a deeper discussion on the subject by those
more knowledgeable than me.
Seaside mailing list
Seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Seaside