So this thing is 2x faster than Envoy, something wrong in the benchmark probably.

mdasen has already pointed out that "2x" seems to overstate the difference by quite a bit. YARP also has a spikier max latency, which I'd expect for a GC'ed language.

I don't see a way to choose the benchmarking platform in the PowerBI dashboard, so I assume all these numbers were collected on Windows. In that case, it doesn't surprise me that YARP is faster: Envoy uses libevent for cross-platform I/O, but libevent is relatively slow on Windows. It exposes Windows-native I/O completion ports as a BSD-style socket API, and the implementation is both inherently somewhat slow and pushes buffering concerns into the Envoy code. Kestrel, YARP's underlying webserver, uses libuv instead. libuv is more actively developed (because of Node.js) and takes the opposite approach, exposing an IOCP-like API even on POSIX systems. Basically, YARP's I/O model is much closer to Windows' native model. This Envoy issue[0] is really informative if you're interested in the details.

More broadly, the .NET team that builds the Kestrel webserver and contributes to YARP and gRPC is full of performance heavyweights. I'd start by assuming that the benchmarks for their projects are thoughtfully designed. Everyone makes mistakes, but start by assuming that James Newton-King, David Fowler, and their peers are brilliant engineers leading a talented team - because they are.

I say all this as someone who doesn't particularly love Windows as a development environment, .NET as a language, or Microsoft as a company (quit after just 6 months). Credit where credit's due.

[0]: https://github.com/envoyproxy/envoy/issues/4952#issuecomment...

Edit: moogly points out that my info on the Kestrel implementation is out of date. Mea culpa!

> Kestrel, YARP's underlying webserver, uses libuv instead

Kestrel (as used in ASP.NET) uses a Socket-based transport since .NET Core 2.1 The libuv transport was marked as obsolete in .NET 5 and has been removed as of .NET 6, I believe.

Ah, good to know! I'm barely C#-literate, so the Socket docs[0] aren't totally intelligible to me. Somewhere under the hood, though, there must be a common abstraction sitting in front of the relevant Windows and Linux syscalls - did the libuv stuff just move down a few layers, or is this using something completely different?

Either way, I'd be shocked if this weren't designed top-to-bottom to have excellent performance on Windows.

[0]: https://docs.microsoft.com/en-us/dotnet/api/system.net.socke...

You can find the Socket partial class files here: https://github.com/dotnet/runtime/tree/main/src/libraries/Sy... Socket.cs, Socket.Unix.cs, Socket.Windows.cs, etc...

AFAIK, there are no parts of libuv left in .NET Core. That was mostly used to quickly get the framework up and running on Linux.

The benchmarks seem to show YARP doing around 35% more requests per second, having around 25% less mean latency, 20% less 90th-percentile latency, and 10% less 99th-percentile latency for http-http. Moving to https-https, it's around 10% more RPS, 10% less mean latency, 15% less 90th-percentile latency, while Envoy has 10% better 99th-percentile latency.

I'm not sure where you're seeing 2x, but it might be the scale of one of the charts you're looking at being deceiving or I'm not looking at the same test you're looking at.

I don't think anyone is using Envoy for peak performance. It is slower than haproxy and nginx but it has other advantages:

* it is super extensible * truly open-source and open to contributions by companies * the codebase is really modern and easy to reason about

Ah, beat me to it :-)

I’m on mobile, and that page is very slow and very tiny. Anyone got a TL;DR?

50% slower than nginx and haproxy

Can you even interpret graphs?