[Seaside] Seaside cache

[Michael Roberts]

I'm not sure how this would work, but one idea might be to reuse the  
REST features in Seaside for generating 'static' URLs or URLs that  
can be reused across sessions.  If you are able to strip off the _s  
and _k parameters when you generate links that you want to consider  
static, then your proxy should be able to cache the content?

Or you leave the _s and _k on your REST generated links but have them  
under a known path and maybe with a rewrite rule (?) get them to be  
considered static and/or strip the _s _k off - since Seaside won't  
care about them anyway if you reuse stale ones.

I'm pretty sure that Lukas' blog, e.g.
http://www.lukas-renggli.ch/blog/blogbugfix? 
command=PRViewCommand&view=PBPostHtmlView
generates links that have no state in.  How does that play with your  
caching requirements?

Cheers,

Mike

On 28 Feb 2007, at 14:48, Ramiro Diaz Trepat wrote:

> 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.
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside