<div>Hi!</div><div><br></div><div>You didn't really answer my question, but you may also want to look into buffering the packets and spawning a process to handle the bufffer. It's a lot more simple than maintaining a pool of worker processes. You only want to do that if you're pooling resources that are expensive to create, something which processes aren't.</div>
<div><br></div>MVH Magnus<br><br><div class="gmail_quote">On Sun, Apr 15, 2012 at 11:41 PM, John-Paul Bader <span dir="ltr"><<a href="mailto:hukl@berlin.ccc.de">hukl@berlin.ccc.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok, little update.<br>
<br>
I've changed the implementation to use {active,false} and a manual gen_udp:recv loop but that made things only slightly faster. Then I commented out the part where I spawned the processes which compute and send back the response to the clients and this gave a _huge_ speed improvement.<br>

<br>
I ran a benchmark on a fast server and could easily handle 100-200k packets per second without losing a single packet.<br>
<br>
So clearly my problem is dispatching the packet/message to the worker processes. I will experiment with a worker pool next instead of spawning the processes on demand.<br>
<br>
If you know how to do this dispatching with as little overhead as possible please let me know.<br>
<br>
~ John<br>
<br></blockquote></div><br>