[erlang-questions] 300k HTTP GET RPS on Erlang 21.2, benchmarking per scheduler polling

[Fred Hebert]

On 12/18, Vans S wrote:
> I think OTHER is something to do with Ports / polling, because I just 
> removed the inet_drv and wrote a simple c nif to do TCP networking, 
> and the throughput doubled. I did not get around to recompiling erlang 
> with microstate accounting but without inet driver using an 
> unoptimized nonblocking tcp nif I got the msacc report to look like
>
>Using 2 schedulers because 10 physical cores generating load now just 
>barely fully saturated.  now 90% of the time is spent in emulator, 6% 
>is other, I am guessing 6% other is the NIF calls to the socket calls?
>
>The throughput was 250k for 2 physical cores.  If all scales linearly 
>that is 1.25m RPS for simple GET hello world benchmark.
>
>The NIF is 
>PoC https://gist.github.com/vans163/d96fcc7c89d0cf25c819c5fb77769e81 ofcourse 
>its only useful in the case there is constant data on socket, otherwise 
>this PoC will break if there is idle connections that keep getting 
>polled.  This opens the possibility though to using something like 
>DPDK.

I think you might have achieved this:

https://twitter.com/seldo/status/800817973921386497

Chapter 15: 300% performance boosts by deleting data validity checks

Of course, the driver may have a higher baseline overhead than a NIF, 
but you also got rid of all validation and handling of any edge case 
whatsoever.

You claim your NIF is not optimized, but it is _extremely_ optimized: 
you removed all code that could have been useful for scenarios that are 
not the one you are actively testing, therefore getting rid of all their 
overheads.

And you are doing so on a rather useless benchmark: hello worlds that 
parse nothing and therefore have nothing in common with any application 
in the wild that might care about the request's content. The benchmark 
results you get can therefore not be extrapolated to be relevant to any 
application out there.

I would likely urge you, unless you are doing this for the fun of 
micro-optimizing edge cases, to consider basing your work on more 
representative benchmarks.