[Seaside] Mac Image Broken?

Wed Jul 13 15:00:31 UTC 2011

Ted,

On 13 Jul 2011, at 16:11, Ted Wrinch wrote:

> Thanks Sven,

You're welcome.

> I know it's high concurrency: I'm testing for high load, 'worst case' scenarios :). 

You are probably looking for some kind of confirmation that Smalltalk/Seaside can handle the load ?

It can, but for most production systems that get some serious load, you will need to do more: put some (reverse) proxy in front of the site, handle static content directly and load balance (with sticky sessions) over several Seaside images, use caching where needed. This has been done before (and it is similar to what needs to be done for other popular stacks like RoR).

Also beware that simply benchmarking Seaside with ab is misleading: Seaside has quite complex and heavy session management, it uses redirects, all requests have a different URL, ... 

FYI, to get an idea of the absolute maximum speed at which a single Pharo could server small static HTTP requests with keepalive, check this 

http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/037875.html

Yes, +2000 req/s is actually possible, but you'll never get that for a real application ;-)

> So you are saying that the listener packet queue is overflowing? And the fix is to increase that. That could explain a lot and I'll poke around and see if the Comanche value for this can be changed. But my guess is that it's buried in the VM somewhere/somehow, as otherwise how would Comanche work in Windows? Perhaps the solution is for me to switch to Zinc? I don't mind either way and your 70-150 requests ps sounds rather good! 

I think Comanche is using 10, but I am not sure (TcpListener class>>backlogSize). 
But that would not explain why it works on Windows ;-)

Zinc is just an option, of which I know the internals a lot better. It is included by default in Pharo 1.3 and higher.

Regards,

Sven

> T.
> 
> Ted Wrinch
> 
> 
> 
> 
> On 13 Jul 2011, at 12:47, Sven Van Caekenberghe wrote:
> 
>> Hi Ted,
>> 
>> I quickly tested on my own main image (Pharo 1.2.2 + Seaside 3.0.3 + Cogit VM), using the ZnZincServerAdaptor (because I know that one best). The problem is the high concurrency level of benchmark combined with the backlog size of the server socket. 
>> 
>> Try lower numbers for -c, like 10 or 20.
>> 
>> For Zinc, the default backlog size for the server socket is 32 (ZnNetworkingUtils class>>#listenBacklogSize). So here, -c 30 works, -c 40 breaks after a couple of hundreds of requests. For other servers, I don't now the default backlog size (or the backlog size when none is specified, which might be platform/vm/os dependent).
>> 
>> I imagine that raising the limit above 50, will make your -c 50 pass.
>> 
>> I terms of performance, I get numbers in the 70 to 150 reqs/s range. My image stays stable.
>> 
>> HTH,
>> 
>> Sven
>> 
>> PS: Currently, #listenBacklogSize is not a settable parameter, but I could change that in Zn.
>> 
>> 
>> On 13 Jul 2011, at 13:18, Ted Wrinch wrote:
>> 
>>> 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. 
>>> 
>>> T.
>>> 
>>> Ted Wrinch
>>> 
>>> 
>>> 
>>> 
>>> On 13 Jul 2011, at 10:17, Sven Van Caekenberghe wrote:
>>> 
>>>> Hi Ted,
>>>> 
>>>> This definitively should not happen.
>>>> 
>>>> So that I can try to reproduce, where did you download the image (link) ? what vm are you using (link) ? what is the exact ab command that you are running ?
>>>> 
>>>> If I would have to guess, maybe this has something to do with networking (dns).
>>>> 
>>>> Sven
>>>> 
>>>> On 12 Jul 2011, at 21:52, Ted Wrinch wrote:
>>>> 
>>>>> Hi All,
>>>>> 
>>>>> I'm using the latest one-click Seaside image ('Pharo1.2.2 Latest update: #12353') on the Mac and notice that:
>>>>> 
>>>>> 1) The image runs 'hot' at 10% CPU.
>>>>> 
>>>>> 2) Loading up Seaside with Apache Bench causes packets to be dropped and for it to give up.
>>>>> 
>>>>> None of these problems occur in the Windows image, which uses no CPU and drops no packets (instead, serving a nice 70 or so requests a second on 50% of a dual CPU MacBook air!).
>>>>> 
>>>>> T.
>>>>> 
>>>>> Ted Wrinch
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside