Hi and Thanks Philippe ;)

>
> 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
> - ...
>
yes that would be cool ;)
>
> Or general answers like: a seaside session uses x MB of RAM and Squeak
> on a Y GHz CPU supports Z concurrent users?
but yes this is exactly the kind of information I'd like to have. I 
imagine it's very dependent of the application itself, but at least 
having a general idea for a generic application (sushi store ?)... and 
also to have comparison data (if possible) of similar app in say php, 
just to compare (even if speculative).  same order ? php with mysql for 
a simple registration app would be able to serve 100 simultaneous 
connections whereas squeak seaside 10 if DBR or 20 if ...

I don't want precise figure but general ones... according to your 
experiences...
>
>> 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.
just a spike... so  it's ok, but under linux, it takes longer...  but 
it's maybe related to the fact firefox(linux) takes more time to render...
> Our general experience is that the persistence is what limits you.
ok. What about persistance in the image ? faster ? probably requires 
more RAM to run squeak ?

If using a database, it's probably better to serve it from another 
server if possible ?

> 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.
I read a post in squeak dev saying that the processor wasn't of first 
importance, but more the RAM...
On a 1Gb server, you'll put -memory 1Gb   or less ?
> - 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.
I had a similar problem before probably due to Comet. Since the priority 
has been changed, I didn't have this problem anymore ;)


Thanks

Cédrick

ps: I think it would be nice to have somewhere in seaside.st the process 
to enter production (prepared image, known vm that works well, ...) as 
well as advices... (persistance,  session management, limits...) ;)