[Seaside] Articles of seaside for production
ssastre at seaswork.com
Mon Mar 12 14:17:28 UTC 2007
> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre
> de Adrian Lienhard
> Enviado el: Lunes, 12 de Marzo de 2007 10:36
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] Articles of seaside for production
> Hi Sebastian
> On Mar 12, 2007, at 14:14 , Sebastian Sastre wrote:
> > I was reading Scaling Seaside from Ramon L. and I finally
> > the path that a Seaside application is going to take for
> scaling from
> > thenths to thousands of users.
> Can you elaborate on your requirements? Do you mean
> concurrent users, each hitting the app once a second?
Basically I want to create an economic metodology to develop solutions from
a prototype to a production application. The production application should
start with a few users and grow to who knows what number. So I wanted to
know at least an average of how many seaside users session a squeak image
can handle witout problems. That article talks something about 10 per image
and I was (before reading) guessing something about 50 so, regarding to that
I was overestimating squeak.
> > I think we need a lot more of detailed articles like this so new
> > people can understand how to mount productive (from development to
> > production) metodologies that match their needs.
> indeed, more experience reports would be interesting...
Yes, it will be only a gain for us all. I will result in more people
experimenting things, having things with good uptimes and more articles
> > I'm saying this because after reading that I read the Ruby scaling
> > strategies and there I've found the basic ideas I was wanting for.
> what are they?
Well, after reading
http://poocs.net/2006/3/13/the-adventures-of-scaling-stage-1 I had a clearer
idea of how a web application, like seaside ones, can make possible to
attend more than a few request per second let's say 4000 for instance. Is
not that I need that now, but anybody wanting to "purchase" the Seaside idea
will be encouraged by this info. In the contrary, the lack of it, will leave
him/she in a uncertainty state. Only very brave people will take the risk
and that is a very little market portion.
> > So I think we need to write more about our experiences !
> In my experience, the bottleneck mostly is the persistency
> and not Seaside (e.g., optimizing Postgres queries was most
> Obviously, this depends on the kind of application you have.
> So you might want to explain your situation and requirements
> and ask for specific advice.
I want not to be worried about persistency until it is strictly necessary.
So I was thinking about persisting in ImageSegments to archieve great
developer's performance by deferring model polution introduced by the
persistence method choosed.
Now I'm wondering how long this strategy could lead me because I'll be able
to use ImageSegments as persistence of a not ACID odb only when I have N
concurrent seaside sessions wich don't compromise the stability of only one
squeak image. So who is N? 10, 50? 1000?
At some point of the "scale" one will have to add more load balanced images
to work serving the application and using some persistancy method that will
make a domain change (objects oustide the worker images).
One can use an image as object server to do this economically but I'm again
in uncertainty about the scale of this object server.
I have no doubts about Gemstone but also no money to buy a license.
Using an OmniBase repository also could solve it at the price of using
OmniBase itself wich easily could break the developer's good performance.
Conclusion: I still have pretty much confidence on the early stage of any
seaside project and pretty much uncertainty of the scale of it.
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside