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

[Frank Muller]

Comparing apples to oranges will certainly mislead you and bias your
benchmark.

We always found Cowboy faster than Elli, Yaws or Misultin to name a few.

We switched to Cowboy in prod few years ago and we didn’t regret it.

The author is doing a great job maintaining it and making the API
consistent, and the doc up to date.

Yes, it’s slower than Nginx but who really cares? Cowboy scales well and
it’s in pure Erlang.

Merry Christmas
/Frank

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.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20181224/d264b8d9/attachment.htm>