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

[Tobias Boege]

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/

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk