http://www.nabble.com/Server-sizing—100-concurrent-users-tf3851191.html#a10940905

My question to you is how many concurrent session can a single image really handle? I saw that you mentioned ‘a few’, but am hoping to get a little more clarity. Considering that my work right now will be mostly ’start-up like’, I need to know if I can scale any of this out on my VPS or not.

Thanks for all the insightful articles and contributions!

I think it is possible to perform caching with Seaside, but not in the traditional way of doing. For sure, you cannot cache the whole content of a page on a front-end. But what about caching pieces of page in the server’s memory ? I personally do it for configuration stuff, such as would be a list of hotels. The only thing you would need to do is perform dynamic replacement of session keys in the cached content - something quite easy and performant with Squeak. The major problem of applications such as one you’re describing is accessing the database - most of the time, this is the real treshold. If you cache the results of your queries in memory - and there’s nothing preventing you of doing it with Seaside - then you would have a very fast generation time. I agree with you, it would not be as fast as a completely cached page. But it would still be fast.
Another approach could be to have static front-end pages querying a back-office Seaside app. This requires to THINK your application differently, but this is also a viable approach. Anyway, Seaside requires to think your app differently.

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.

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 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.

i mean, is it after every request persisted to some kind of database,
like it happens with shared-nothing architectures (rails,django etc.)?

because if not, then when you load-balance, you have to make sure
that all the requests for a certain session arrive at the same seaside-instance, or not?

so, how is it with seaside?