TCP stack throughput
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
>>> 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
>>> What do you folks recon?
>> 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
>> running one.
> I'm with Mickael.
> Your results could be interpreted as showing one _or more_ of the
> 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.
More information about the erlang-questions