[Gambas-user] ServerSocket doesn't appear to scale well

[Benoît Minisini]

Le 31/03/2019 à 12:44, Tobias Boege a écrit :
> On Sat, 30 Mar 2019, T Lee Davidson wrote:
>> Okay so I coded up a multi-socketed server loosely based on the "Network
>> Programming" example [0]. (I found that there's no need to maintain an array
>> of Socket objects.)
>>
>> I ran some tests using the Apache HTTP benchmark tool ('ab'). When sending
>> the server 100 total and concurrent requests, it's performance is relatively
>> impressive: Time taken for tests: 0.032 seconds.
>>
>> But, if I hammer it with much more than 100 concurrent requests (about
>> 150-200 I think), it starts to choke creating new connection Sockets very
>> slowly. Even at only 100 requests, a test will sometimes not complete due to
>> a time-out.
>>
>> Any suggestions as to why that might be, and what I could do to open it up?
>>
>> Here's what I have:
>>
> 
> I think you can't do better in Gambas than your code. I'm not saying that
> the performance can't be improved in Gambas, but I doubt that you can do
> it from a Gambas program. Starting a Task for every connection would most
> likely not help you here as your connections are very short-lived.
> 
> My suspicions point in the direction of select(), particularly [1,2] and
> the benchmark by libevent [3] linked there. The caption [4] of that image
> reads: "The benchmark measures how long it takes to serve one active
> connection [ under the indicated load of other active file descriptors,
> I suppose ] and exposes scalability issues of traditional interfaces
> like select or poll".
> 
> Maybe it is the performance characteristics of select() and the number
> of sockets you deal with that cause the problem. It would be interesting
> to substitute one of the better-scaling multiplexing mechanisms according
> to [3] for select() [ even though we need level-triggered IO notification
> for Gambas events and [2] does not list anything on Linux besides poll()
> and select() ]. I'm not sure how much work it is to just try it out with
> epoll(), but it might not be so much as all mentions of "select" and
> "FD_SET" are confined to gbx_watch.c. Consider me interested, but I have
> to give and take some Sunday visits today.
> 
> That's just one idea though.
> 
> Regards,
> Tobi
> 
> [1] https://stackoverflow.com/questions/142677/how-to-most-efficently-handle-large-numbers-of-file-descriptors
> [2] http://www.kegel.com/c10k.html
> [3] https://monkey.org/~provos/libevent/libevent-benchmark.jpg
> [4] http://libevent.org/
> 

Yes, replacing select() by poll() is something to be done.

But I don't think that it explains why creating socket become suddenly 
very slow after a specific number of socket. The slow down should be 
linear if it comes from Gambas.

Regards,

-- 
Benoît Minisini