distributed performance test

Sean Hinde sean.hinde@REDACTED
Mon Apr 25 19:17:16 CEST 2005

On 25 Apr 2005, at 17:49, Serge Aleynikov wrote:

> Sean Hinde wrote:
>>> P.S. The only question I have remaining is why would half-duplex 
>>> setting not have any speed impact on a single client talking to a 
>>> synchronous server, but only on multiple clients...
>> Well, I guess that a single client is actually only exercising half 
>> of a duplex. There is never any time when traffic wants to flow both 
>> ways at the same time.
> You know, I forgot to mention another interesting fact.  When I tried 
> to troubleshoot this issue, I extended my test_client/test_server to 
> be able to send/receive messages using three transports: 
> erlang/tcp/udp. Here are the results of my tests when the eth0 was set 
> to half-duplex:
> (n1@REDACTED)15> test_client:test_erl(n2@REDACTED, 10, 500).
>   -> AvgTime=0.022 (45.360 c/s)
> (n1@REDACTED)17> test_client:test_udp({10,227,1,200}, 10, 500).
>   -> AvgTime=0.000 (3355.705 c/s)
> (n1@REDACTED)18> test_client:test_tcp({10,227,1,200}, 10, 500).
>   -> AvgTime=0.000 (3144.654 c/s)
> So, if your statement were true, then it would've had impact on all 
> tcp/udp/erlang transports, wouldn't it?  Yet in this case somehow it 
> only impacted Erlang's message passing speed.
> After converting eth0 to full-duplex:
> (n1@REDACTED)19> test_client:test_erl(n2@REDACTED, 10, 500).
>   -> AvgTime=0.000 (2450.980 c/s)
> (Note: it's still a bit slower than when using TCP/UDP sockets).

Yes, this also matches with my experience. In fact it prompted us to 
write our own simpler RPC mechanism as we needed extreme performance 
for one of our applications.

It would be interesting to run profilers and trace to see where the 
extra time has gone. I have never used it, but erlsnoop might be 



More information about the erlang-questions mailing list