TCP stack throughput

[Sean Hinde]

I had some discussions once with some folks who were deploying ad 
server type systems - lots of very short lived connections. The game 
was all about winding down time wait etc until the tcp stack stopped 
running out of port numbers. They had a funky in house designed C web 
server with OS threads, which did work mostly.

OTOH if you are the one controlling the client behaviour then you can 
ensure they use persistent connections where possible.

Sean

On 4 Jul 2005, at 22:34, Matthias Lang wrote:

> Mickael Remond writes:
>> Joel Reymont wrote:
>>> So this means 500 simultanous connection requests on Solaris and  
>>> about
>>> 300 on Mac OSX (FreeBSD). My question, I suppose, is whether  this is
>>> high enough.
>>>
>>> Is there a limitation in Erlang or is this maxing out the platform  
>>> TCP
>>> stack?
>>>
>>> What do you folks recon?
>>
>> Hello,
>>
>> I am not sure I understand your test quite well. Basically you are
>> connecting and deconnecting very quickly. Is that the case ?
>> If this is the case, what are you trying to benchmark ?
>> Most of the time mesuring the TCP/IP throughput implies trying to know
>> how much data can be processed through a TCP socket, but usually a 
>> long
>> running one.
>
> I'm with Mickael.
>
> Your results could be interpreted as showing one _or more_ of the
> following:
>
>    a) That your test client is the bottleneck
>
>    b) That your test server is the bottleneck
>
>    c) That the OS/tcp stack isn't really designed for the sort of
>       use you're testing.
>
> My gut feeling says (c), mainly because different people are reporting
> fairly different behaviour from one OS to another. I've written a
> quick and dirty C server which does something similar enough to the
> erlang server to work with your client. You could experiment with it
> to try and eliminate hypothesis (b).
>
> The program works for me on linux 2.6.x.
>
> Matthias
>
> <server.c>