distributed performance test

[Sean Hinde]

Sorry, I have no idea whatsoever on that one.

Sean

On 25 Apr 2005, at 18:26, Serge Aleynikov wrote:

> Thanks Sean,  I'll play with erlsnoop when I have more time.
>
> For now the only outstanding issue I have is listed here:
>
> http://www.erlang.org/ml-archive/erlang-questions/200504/msg00274.html
> http://www.erlang.org/ml-archive/erlang-questions/200504/msg00286.html
>
> If you happened to have similar experiences, please do let me know.  
> :-(
>
> Regards,
>
> Serge
>
> Sean Hinde wrote:
>> 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 
>> helpful:
>> http://www.erlang.org/contrib/erlsnoop-1.0.tgz
>> Sean