Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft YARP

github.com

Post reply on HN
Print view View original

21–30 of 153 posts

Re: Microsoft YARP

#21

Post by mdasen »

Thaxll wrote: post #13
mdasen wrote: post #5

Earlier quoted context omitted.

https://devblogs.microsoft.com/dotnet/announcing-yarp-1-0-re... https://aka.ms/aspnet/benchmarks (click on the "1 of 21" pagination at the bottom of the page and select "Proxies"). You can compare it to nginx, envoy, and haproxy.

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

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.

Re: Microsoft YARP

#22

Post by qbasic_forever »

bob1029 wrote: post #18
oneplane wrote: post #14

Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists. While having many implementations to choose from if you need to select a solution to an outstanding problem is great, it makes me wonder why re-implementing something with no discernible benefit keeps eating time/resources all over the place. In similar cases of implementing reverse proxies in C, C++, Rust,…

> re-implementing something with no discernible benefit keeps eating time/resources all over the place. > is a shame considering the benefits of pooling resources on existing implementations would have. What exactly would you prefer these developers spend their time on instead of this work? There are a lot of benefits to being able to integrate your own reverse proxy directly into your software stack. C# developers e…

No post body was provided.

Re: Microsoft YARP

#23

Post by civilized »

123pie123 wrote: post #17
oneplane wrote: post #14

Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists. While having many implementations to choose from if you need to select a solution to an outstanding problem is great, it makes me wonder why re-implementing something with no discernible benefit keeps eating time/resources all over the place. In similar cases of implementing reverse proxies in C, C++, Rust,…

>Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists It sometimes feels to me, like a huge percentage of developers reinvent the wheel

There are thousands of Java accounting apps and thousands of shitty medical billing websites.

I think most devs are definitely reinventing the wheel for the ten thousandth time

Re: Microsoft YARP

#24

Post by cakoose »

oneplane wrote: post #14

Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists. While having many implementations to choose from if you need to select a solution to an outstanding problem is great, it makes me wonder why re-implementing something with no discernible benefit keeps eating time/resources all over the place. In similar cases of implementing reverse proxies in C, C++, Rust,…

To clarify, are you saying that:

1. There are already good reverse proxy libraries in C#?

2. There are already good reverse proxy libraries in other languages?

3. There are already good reverse proxy applications?

If it's #1, then yeah, it would be nice if the ReadMe explained why YARP is different. To be fair, they're at least consolidating a bunch of efforts within Microsoft:

> We found a bunch of internal teams at Microsoft who were either building a reverse proxy for their service or had been asking about APIs and tech for building one, so we decided to get them all together to work on a common solution, this project.

If it's #2, then what do C# developers do? Having to build your proxy in another language isn't a deal-breaker, but there are advantages to keeping your project/team/company on a single language.

(And Microsoft does contribute to Envoy [1][2].)

If it's #3, that only works up to a point. My old team used Nginx, which was perfect in the beginning. But over time we needed to customize things in ways that were difficult to do within Nginx's architecture (either in Lua or in C), leading to hackier and hackier solutions. Using a proxy library to build exactly what you need can make things much simpler.

[1] https://blog.envoyproxy.io/general-availability-of-envoy-on-...

[2] https://techcrunch.com/2020/08/05/microsoft-launches-open-se...

Re: Microsoft YARP

#25

Post by bob1029 »

cakoose wrote: post #24
oneplane wrote: post #14

Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists. While having many implementations to choose from if you need to select a solution to an outstanding problem is great, it makes me wonder why re-implementing something with no discernible benefit keeps eating time/resources all over the place. In similar cases of implementing reverse proxies in C, C++, Rust,…

To clarify, are you saying that: 1. There are already good reverse proxy libraries in C#? 2. There are already good reverse proxy libraries in other languages? 3. There are already good reverse proxy applications ? If it's #1, then yeah, it would be nice if the ReadMe explained why YARP is different. To be fair, they're at least consolidating a bunch of efforts within Microsoft: > We found a bunch of internal teams a…

> But over time we needed to customize things in ways that were difficult to do within Nginx's architecture (either in Lua or in C), leading to hackier and hackier solutions. Using a proxy library to build exactly what you need can make things much simpler.

This is the central argument for me regarding why we don't "just use nginx". We actually do use it for some corporate websites, but not for our main product.

There is a ton of power hiding here... With a well-supported first-party RP framework, how long would it take for a determined developer to replicate the most important bits of the nginx feature set? Imagine being able to throw a blazor dashboard on top of this stuff. Wiring up real-time events/metrics would be super trivial if you are even remotely interested in learning how the DI system operates. Mix in a little bit of SQLite and you could have something I may argue provides a better UX than what nginx offers today.

Re: Microsoft YARP

#26

Post by davinci26 »

Thaxll wrote: post #13
mdasen wrote: post #5

Earlier quoted context omitted.

https://devblogs.microsoft.com/dotnet/announcing-yarp-1-0-re... https://aka.ms/aspnet/benchmarks (click on the "1 of 21" pagination at the bottom of the page and select "Proxies"). You can compare it to nginx, envoy, and haproxy.

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

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

Re: Microsoft YARP

#28

Post by akshayshah »

Thaxll wrote: post #13
mdasen wrote: post #5

Earlier quoted context omitted.

https://devblogs.microsoft.com/dotnet/announcing-yarp-1-0-re... https://aka.ms/aspnet/benchmarks (click on the "1 of 21" pagination at the bottom of the page and select "Proxies"). You can compare it to nginx, envoy, and haproxy.

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!

Re: Microsoft YARP

#29

Post by jeeeb »

bob1029 wrote: post #18
oneplane wrote: post #14

Sometimes it feels like Microsoft and/or C#-enjoyers just want to re-implement everything that already exists. While having many implementations to choose from if you need to select a solution to an outstanding problem is great, it makes me wonder why re-implementing something with no discernible benefit keeps eating time/resources all over the place. In similar cases of implementing reverse proxies in C, C++, Rust,…

> re-implementing something with no discernible benefit keeps eating time/resources all over the place. > is a shame considering the benefits of pooling resources on existing implementations would have. What exactly would you prefer these developers spend their time on instead of this work? There are a lot of benefits to being able to integrate your own reverse proxy directly into your software stack. C# developers e…

> There are a lot of benefits to being able to integrate your own reverse proxy directly into your software stack. C# developers enjoy these as much as anyone else would.

I take this at face value but it would be nice to know what the benefits are vs nginx and other off the shelf solutions.

The readme explains the benefit for Microsoft but not how it stacks against off the self solutions.

Re: Microsoft YARP

#30

Post by rafale »

How does this compare to nginx? Does it support websockets? I have an asp.net core websocket based app that need to support hundred of thousands concurrent websockets connection. I ll be taking a look at this because I don't wanna expose Kestrel directly to the internet.
Post reply on HN