<div><div dir="auto">Comparing apples to oranges will certainly mislead you and bias your benchmark.<br></div><div dir="auto"><br></div><div dir="auto">We always found Cowboy faster than Elli, Yaws or Misultin to name a few.</div></div><div dir="auto"><br></div><div dir="auto">We switched to Cowboy in prod few years ago and we didn’t regret it.</div><div dir="auto"><br></div><div dir="auto">The author is doing a great job maintaining it and making the API consistent, and the doc up to date.</div><div dir="auto"><br></div><div dir="auto">Yes, it’s slower than Nginx but who really cares? Cowboy scales well and it’s in pure Erlang.</div><div dir="auto"><br></div><div dir="auto">Merry Christmas</div><div dir="auto">/Frank</div><div dir="auto"><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/18, Vans S wrote:<br>
> I think OTHER is something to do with Ports / polling, because I just <br>
> removed the inet_drv and wrote a simple c nif to do TCP networking, <br>
> and the throughput doubled. I did not get around to recompiling erlang <br>
> with microstate accounting but without inet driver using an <br>
> unoptimized nonblocking tcp nif I got the msacc report to look like<br>
><br>
>Using 2 schedulers because 10 physical cores generating load now just <br>
>barely fully saturated.  now 90% of the time is spent in emulator, 6% <br>
>is other, I am guessing 6% other is the NIF calls to the socket calls?<br>
><br>
>The throughput was 250k for 2 physical cores.  If all scales linearly <br>
>that is 1.25m RPS for simple GET hello world benchmark.<br>
><br>
>The NIF is <br>
>PoC <a href="https://gist.github.com/vans163/d96fcc7c89d0cf25c819c5fb77769e81" rel="noreferrer" target="_blank">https://gist.github.com/vans163/d96fcc7c89d0cf25c819c5fb77769e81</a> ofcourse <br>
>its only useful in the case there is constant data on socket, otherwise <br>
>this PoC will break if there is idle connections that keep getting <br>
>polled.  This opens the possibility though to using something like <br>
>DPDK.<br>
<br>
I think you might have achieved this:<br>
<br>
<a href="https://twitter.com/seldo/status/800817973921386497" rel="noreferrer" target="_blank">https://twitter.com/seldo/status/800817973921386497</a><br>
<br>
Chapter 15: 300% performance boosts by deleting data validity checks<br>
<br>
Of course, the driver may have a higher baseline overhead than a NIF, <br>
but you also got rid of all validation and handling of any edge case <br>
whatsoever.<br>
<br>
You claim your NIF is not optimized, but it is _extremely_ optimized: <br>
you removed all code that could have been useful for scenarios that are <br>
not the one you are actively testing, therefore getting rid of all their <br>
overheads.<br>
<br>
And you are doing so on a rather useless benchmark: hello worlds that <br>
parse nothing and therefore have nothing in common with any application <br>
in the wild that might care about the request's content. The benchmark <br>
results you get can therefore not be extrapolated to be relevant to any <br>
application out there.<br>
<br>
I would likely urge you, unless you are doing this for the fun of <br>
micro-optimizing edge cases, to consider basing your work on more <br>
representative benchmarks.<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></div>