[erlang-questions] UDP receive performance

Lukas Larsson lukas@REDACTED
Wed Jun 20 19:06:21 CEST 2018

On Wed, Jun 20, 2018 at 1:56 PM Jonas Falkevik <
jonas.falkevik@REDACTED> wrote:

> Are you adding the multicast network to the loop back interface? Using
> some other interface that does not allow multicast traffic?
I though I had, but apparently not.... I managed to reproduce the test case

I also spent some time staring at the code in the inet_driver and realized
what the problem was in there. It would seem that a performance/feature fix
for SCTP in R15B inadvertently introduced this behaviour for UDP :( I've
pushed a bug fix to that problem in the inet_driver to the same branch. In
my tests the scheduler utilization goes form 71% to about 4% with both
patches. With the fix in the inet driver, my allocator patch does not
really do any difference for this specific testcase, but I'll keep that fix
anyways as it is a "good thing". I should probably also add a benchmark for
this so that it does not happen again....

I'd also like to add that changing the test-case to use a smaller
user-space buffer also has the same effect. So if anyone is running a
performance critical UDP server that has set the "recbuf" to a high value,
I really recommend that you lower the "buffer" size to something close to
the max expected packet size. In the example that Danil provided I applied
the following patch:

diff --git a/udptest.erl b/udptest.erl
index 16a1798..4edeef0 100644
--- a/udptest.erl
+++ b/udptest.erl
@@ -33,7 +33,9 @@ send_packet(ID, S, Addr, Port) ->

 start_reader(Addr, Port) ->
   GwIP = {0,0,0,0}, % {127,0,0,1},
-  Common =
+  Common = [binary,{reuseaddr,true},
+            {buffer,1500}, %% 1500 is just an example value, don't just
copy this. You need to know what you max UDP packet size will be.
+            {recbuf,2*1024*1024},inet,{read_packets,100},{active,500}],
   Multicast =
   Options = Common ++ Multicast,
   spawn(fun() -> run_reader(Port, Options) end).

and the scheduler utilization dropped to about 4% there as well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180620/4a82d4d1/attachment.htm>

More information about the erlang-questions mailing list