On Thu, Jul 14, 2011 at 8:07 PM, Philippe Marschall
<philippe.marschall at gmail.com> wrote:
> 2011/7/13 Ted Wrinch <ted.wrinch at gmail.com>:
>> Hi Sven,
>> It was the one-click, all in image from the Seaside site: see the link ''
>> 'Seaside One-Click Experience
>> 3.0.5 at http://www.seaside.st/download/pharo?_s=f6qFOGN_O20lpSoB&_k=TF27rUzr&_n&26.>> The VM is part of the one-click and I believe is the
>> 'Seaside.app/Contents/MacOS/Squeak VM Opt' file - I'm not quite sure what it
>> is as the Mac thinks it's a text file, and not a Unix binary or shell
>> script. The ab command was 'ab -c50 -n1000
>> "http://127.0.0.1:8080/javascript/jquery-ui"', and it fails after posting
>> 400 packets or so. I think that the use of the loop back address means that
>> it can't be using DNS. My guess, from some of the older list comments, was
>> that perhaps this VM is still built using polling for events, rather than
>> handling them on interrupts, which could explain packet loss and suggest an
>> inefficient UI loop.
>> While this is nice because it may give you nice numbers it's important
> to remember that this does nothing have to do with what you'll see in
> production. Everything you will see in production, bottlenecks,
> throughput, latencies, memory usage, cpu usage will be drastically
> different. The numbers you'll get have absolutely no significance.
> You'll probably benchmark how fast Seaside can create new sessions
> because every request creates a new session.
Actually, probably how fast your Smalltalk iterates over large
dictionaries, since every 10th request triggers reaping of expired
sessions. :) Since that also enters a critical section, you would at a
minimum want to increase that number (10) to something substantially
higher. Really, if you were expecting a high volume of sessions, you
would want to use a different strategy for clearing out expired
sessions altogether.
Julian