Seaside Performance, QoS (was: Smalltalk Web Host Opens)

Philippe Marschall philippe.marschall at gmail.com
Wed Dec 13 11:07:07 UTC 2006


2006/12/12, Cédrick Béler <cbeler at enit.fr>:
>
> >> I don't know what virtual hosting mechanism
> >> underlies the two sites, but I think there
> >> is an "apples to oranges" comparision here.
> >
> > That has been discussed on the seaside mailinglist too. It uses a
> > technique similar to DabbleDB.
> > Honestly I don't see how you get anywhere with 32 MB and Squeak/Seaside.
> same, and especially, I found the demo very slow (counter, multi) on
> firefox from linux and windows...
>
> just to give an idea, I have a server for 30€/month
> (www.dedibox.fr or www.dediboxinternational.com (same but more
> expensive...))
> -160Gb HD
> -1go Ram
> -up/dw unlimited
> -the proc is non standard though (VIA C7 2Gh with material ssl...)
> ...
> -but of course no support, ... etc...
>
> So, of course, I'm not asking for same characteristics for
> seasideparasol, but at least decent RAM and HD, especially if targeted
> to be multi web paradgm (php, pearl...) and also, a good quality of
> service of the connection...
>
> So more thant a critic, I'd like to have information on performance
> (QoS) with seaside... compared maybe to others servers-side application
> framework (php , java...). I'm too newbie to know that and I'd like to
> see what people thinks...

What do you mean, would you like to have better logging and profiling like
- time used to process callbacks
- time used to render
- memory usage
- number of session
- memory use of sessions
- ...


Or general answers like: a seaside session uses x MB of RAM and Squeak
on a Y GHz CPU supports Z concurrent users?

> On the server I mentionned, using a debian, I notice that only hitting a
> seaside app. led to 50-60% proc use. Is it normal ?

Continuous or just a spike to answer the request? The later is normal,
the former not.

> In this case, how
> many simultaneaous connection could It support ?

This is so much application and dependent there can not be a general
answer to that.

> On windows (dual core), around 20-30%... I juste closed opened
> Transcripts and cleaned a bit the image... I know there are better
> optimisation. Bur according to your experience, with a prepared
> production image, what could we expect as QoS ? when do we need to load
> balance, how to ? etc ...

Our general experience is that the persistence is what limits you.
This depends on so many factors that only you can answer this.

Squeak does not care about dual cores or SMP and it is good that way.

> I think this is a very important information especially for people who
> want to enter production. What do do ? what not to do ?
> For instance, at the last smalltalk party in Paris, I met a  guy who
> developped in Seaside and who was encountering problem of image frozen
> when load testing (under Linux).

This is common for some applications. There are two problems here:
- One is that the vm hits the memory limit (128 MB per default).
Symptom: image is frozen at 100% CPU. You can try to play around with
the -memory and -mmap parameters. That might make it to appear less
often.
- The other is that gui is frozen. Symptom: image is frozen at 0% CPU.
Suspending and resuming the UI with the screenshot application several
times might make the ui reacting again until it freezes the next time.

As a general solution to any kind of problem: ask on squeak-dev or the
seaside mailing list.

Philippe

> Thanks for any information
>
> Cédrick
>
>
> ps: I also noticed that using firefox on linux, was far slower than
> using firefox on windows (for the rendering)... which is why I came back
> to windows... (anyway, it's more a problem with Linuw I guess than with
> squeak).
>
>
>
>


More information about the Squeak-dev mailing list