<div dir="ltr">On what basis do you make that claim? Also, writing a NIF that actually provides better performance without blocking the scheduler is non-trivial, even if UDP is simple to work with in C.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 2:52 AM, Sergej Jurečko <span dir="ltr"><<a href="mailto:sergej.jurecko@gmail.com" target="_blank">sergej.jurecko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>UDP performance in erlang is not that good. If I were you I would write a NIF. UDP is relatively simple to work with in C/C++. <br><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">Sergej<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 8:40 PM, Ameretat Reith <span dir="ltr"><<a href="mailto:ameretat.reith@gmail.com" target="_blank">ameretat.reith@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm playing with Erlang to make an experimental protocol.  I'm trying<br>
to make it use full of 1Gbit link but It won't scale that much and I'm<br>
failing to found a bottleneck in my code or even anything I could call<br>
it bottleneck.<br>
<br>
My software is very like a messaging server software in behavior, with<br>
bigger packets, many clients (more than 4k) and uses more complex<br>
sub-components, like a distributed database but those components are<br>
not blocking other portions of system;  It's just the client-server<br>
channel that is heavy IO and involve some encryption and decryption.<br>
<br>
I made a gen_server process for each UDP socket to clients.  There is a<br>
central process registry but It being called just for new clients and<br>
Its message queue is often empty.<br>
<br>
I found there was a bottleneck in `scheduler_wait` when I had few<br>
clients (around 400) and It consumed around 50% of total CPU usage.  I<br>
found an old patch by Wei Cao [1] which seemed to target same issue.<br>
But on a modern version of Erlang (18.0) blockage in `scheduler_wait`<br>
dropped well in more congested network, specifically to around 10%<br>
when my software reached Its apparent limit, around 600Mbit/s read and<br>
write to network. At this point my incoming UDP packet rate is around<br>
24K/s. Maybe an experienced Erlang developer here can remember that<br>
problem and can tell whether Erlang is now optimized to poll for<br>
network packets more often or not..<br>
<br>
I also concerned async pool since there was fairly high work in Erlang<br>
work with pthread but found those threads just used for file IO<br>
operations.  I didn't found any assuring documentation about this, just<br>
saw the only user of this dirty IO thing is `io.c` in otp source code.<br>
I'm very grateful if anyone clear the usage and effect of this pool.<br>
<br>
<br>
I made flame graphs of function calls both inside VM (using eflame2<br>
[2]) which is very even and cannot find any outstanding usage [3]. And<br>
made another flamegraph of perf report outside of VM which cannot find<br>
some symbols [4].  I doubt whether process_main shoud take that much<br>
work itself or not.  Apparently encryption and decryption (enacl_nif<br>
calls) didn't take much time too.<br>
<br>
Do you have any suggestion for me to analyze better my software and<br>
understand VM working?  Is It those limits I should expect and there is<br>
not more room for optimizations?<br>
<br>
Thanks in advance<br>
<br>
1: <a href="http://erlang.org/pipermail/erlang-questions/2012-July/067868.html" rel="noreferrer" target="_blank">http://erlang.org/pipermail/erlang-questions/2012-July/067868.html</a><br>
2: <a href="https://github.com/slfritchie/eflame" rel="noreferrer" target="_blank">https://github.com/slfritchie/eflame</a><br>
3: <a href="http://file.reith.ir/in-erl-3k.gif" rel="noreferrer" target="_blank">http://file.reith.ir/in-erl-3k.gif</a><br>
4: <a href="http://file.reith.ir/out-erl-perf.svg" rel="noreferrer" target="_blank">http://file.reith.ir/out-erl-perf.svg</a> (interactive, use web browser)<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>