Seaside cache
Locked
 
|
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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> 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 great. 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. Ramon Leon http://onsmalltalk.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside cache
|
|
In reply to this post by Ramiro Diaz Trepat
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? _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Ramiro Diaz Trepat
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 > [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 |
|
|
> 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? So, this means that all the state is in the URL. There are different places in the Pier blog plugin where it creates REST-ful but stateless URLs, just to avoid that everybody updating its feed creates a new session. Pier creates REST-ful and state-full URLs by default, this means the URLs can be bookmarked but Seaside will only try to parse them if the state has been thrown away (aka the session expired). A possible strategy for your caching problem would be to do the following. I don't really know if it is worth the pain, make sure that you don't optimize too early: - Create REST-ful URLs for all the parts of the application that should be cached. Make sure that you add a special URL parameter to all the parts that should be served dynamically. - Let Apache cache all the pages that don't have the special parameter. Do a fallback to the Seaside image if you encounter the parameter or if the requested URL is missing in the cache. It sounds quite simple, but I guess there are some tricky hidden parts somewhere in-between. I guess that especially the conversion from the cached to the dynamically created contents and vice versa, could turn out not that trivial. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
>
> So, this means that all the state is in the URL. There are > different places in the Pier blog plugin where it creates > REST-ful but stateless URLs, just to avoid that everybody > updating its feed creates a new session. Pier creates > REST-ful and state-full URLs by default, this means the URLs > can be bookmarked but Seaside will only try to parse them if > the state has been thrown away (aka the session expired). > > A possible strategy for your caching problem would be to do > the following. I don't really know if it is worth the pain, > make sure that you don't optimize too early: > > - Create REST-ful URLs for all the parts of the application > that should be cached. Make sure that you add a special URL > parameter to all the parts that should be served dynamically. > > - Let Apache cache all the pages that don't have the special > parameter. Do a fallback to the Seaside image if you > encounter the parameter or if the requested URL is missing in > the cache. > > It sounds quite simple, but I guess there are some tricky > hidden parts somewhere in-between. I guess that especially > the conversion from the cached to the dynamically created > contents and vice versa, could turn out not that trivial. > > Cheers, > Lukas Yea, but what the restrictions be for those pages.... no Ajax? I don't see Scriptaculous working well on such pages, and I don't write much code without using Scriptaculous. Ramon Leon http://onsmalltalk.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> Yea, but what the restrictions be for those pages.... no Ajax? I don't see
> Scriptaculous working well on such pages, and I don't write much code > without using Scriptaculous. That should be possible as well, as long as the AJAX responses are REST-ful and completely static. But yes, this complicates things even more ... Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
| Free forum by Nabble | Edit this page |