TCP stack throughput

Sean Hinde <>
Tue Jul 5 01:05:51 CEST 2005

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.


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>

More information about the erlang-questions mailing list