Articles of seaside for production

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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?

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

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

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

Cheers,
Adrian
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

2007/3/12, Sebastian Sastre <[hidden email]>:
Then why do you worry about Seaside performance before it is strictly
necessary? This seems very inconsistent to me.

Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

That solution works for today, but long term I would point to the Yaws
vs. Apache comparison.  I think  using very low level languages to write
important services is going to become less and less desirable, as well
as productive.  When Exupery gets a bit better I plan on running a
Exupery image with Comanche optimized as my server.  I see no technical
reason that Squeak can't be made to run a web server as fast as Yaws can
(though I'm sure it will take some work).

Sebastian Sastre wrote:
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside