[erlang-questions] UDP client/server performance
Dmitry Kolesnikov
dmkolesnikov@REDACTED
Sat Aug 18 15:52:02 CEST 2012
Hello,
I would slightly disagree with your evaluation approach on UDP performance. It is obvious that Erlang code is slower to compare with C code. Therefore, any single threaded benchmark would always show a highest performance of C code. You have to push it in multi client env... I've re run you test cases and got a bit different results with vanilla gen_udp.
So, the lowest latency of inter packet arrival time on Erlang is about 16-17 usec. This is the time used by underlying SW stack to process packet and deliver it to application process. I did not managed to get any lower latency on my hw (Mac Lion Server).
Async case: pure C solution handled about 341K packet/sec, erlang server runs 256K packet/sec. One of the biggest problem for async is high packet drop rate in both C & Erlang cases.
Sync case: pure C solution handled about 160K packet/sec, erlang server runs 45-50K packet/sec.
Regards, Dmitry
On Aug 15, 2012, at 5:03 PM, Michael Santos wrote:
> On Wed, Aug 15, 2012 at 09:59:22AM +0200, Ronny Meeus wrote:
>> On Wed, Aug 15, 2012 at 2:53 AM, Michael Santos
>> <michael.santos@REDACTED> wrote:
>>> On Tue, Aug 14, 2012 at 10:10:57PM +0200, Ronny Meeus wrote:
>>>> Hello
>>>>
>>>> thanks for the info.
>>>> I'm currently playing with the procket and it is working well.
>>>>
>>>> I have 2 questions:
>>>>
>>>> - I need to run the erl as root (or use sudo to start it) or I get:
>>>>
>>>> 2> {ok, FD} = procket:open(53, [{protocol, udp},{type, dgram},{family, inet}]).
>>>> ** exception error: no match of right hand side value {error,eperm}
>>>
>>> Make priv/procket setuid or allow your user to call priv/procket using
>>> sudo.
>>
>> I tried all options mentioned in your readme already before but non of
>> them seem to work on Ubuntu. I think there is an issue with the sudo
>> stuff on this distribution since no matter what I do, it always ask
>> for a password when the procket command is executed.
>>
>> Now I succeeded by explicitly specifying the name of the program to use:
>> procket:open(53, [{progname,"/usr/local/bin/procket"},{protocol,
>> udp},{type,dgram}]).
>
> procket uses priv/procket as the default path. Sorry, README should be
> clearer.
>
>>>> - How do I use recvfrom/4 in the server? If I call recvfrom/4 when
>>>> there is no message present in the socket, it returns an error since
>>>> the socket is put in async mode.
>>>
>>> Yes, the socket has to be non-blocking or it will block the scheduler.
>>>
>>>> Does this mean that the socket needs
>>>> to be polled by the Erlang process or is it possible to get a
>>>> notification (msg) when there is data present in the socket so that
>>>> the recvfrom/4 can be called at that moment?
>>>
>>> You could plug the fd back into gen_udp:open(Port, [{fd, FD}]) ;)
>>>
>>> For a UDP socket, I can't think of any options other than the ones
>>> you've mentioned: either spin on EAGAIN or use another NIF to notify you
>>> when the socket is ready. There are a few ports to libev and libuv around.
>>
>> OK I will look around.
>> Thanks.
>>
>> Yesterday I did a quick test and created an application that once it
>> receives a message, it starts to send this back in a loop.
>> It looks like it is able to send almost 200Kpkts/sec on a low end PC
>> while the gen_udp solution only was able to send something like
>> 10Kpks/sec on a much more powerful PC. So it looks promising ...
>
> That's cool! But remember, the C and the Erlang examples you posted are
> doing different things. The C code is single tasking. It doesn't do any
> error handling either. The Erlang code is multitasking, switching
> between processes, monitoring processes for failure, ....
>
> If you run C NIF code in a tight loop, you'll get something closer to
> the single tasking C code at the expense of concurrency. Maybe that is
> fine for your needs though. Anyway, good luck in hitting your numbers!
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list