[Seaside] Articles of seaside for production

[Philippe Marschall]

2007/3/12, Sebastian Sastre <ssastre at seaswork.com>:
> > -----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
> > understood
> > > 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
> written.
>
> >
> > >  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
> > effective).
> > 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.

Then why do you worry about Seaside performance before it is strictly
necessary? This seems very inconsistent to me.

Philippe

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