Linux vs. Windows hosted .NET Core application performance analysis | Hacker News Reader

Linux vs. Windows hosted .NET Core application performance analysis

robertoprevato.github.io

31 pointsevo_910 comments

Read the entire article, only to see at the end that this is from 2017.

> Written on October 26, 2017

What would change since? Not surprised Linux wipes the floor with windows on total throughput as the system is heavily optimized for that. Would be interested to see tail latency stats as the avg isn’t very useful.

The .NET Core runtime was heavily oprimized in the last years so yes it would make a difference for the numbers. Not sure if Azure makes any difference, but in prod setups where some clients insist on Windows but most use Linux, we see that Linux easily wins.

So that means the gap is even wider now? The numbers in that post look like what i would expect for just any multi-threaded application on win vs linux

600 requests per second for a hello world not even hitting a database? Are the units right? Shouldn't it be in kilo-requests per second?

Seems low, yes. I get~500k RPS when running Rust API servers returning JSON on WSL2 on Windows.

(No DB, DB calls decreases that 10x).

As a point of reference, I once wrote an ASP.NET application in 2005 that could easily put out 2000-3000 full-text search result web pages per second... on a 2-core laptop. These days .NET Core 5 is challenging Rust in the web server rankings, so anything less than 10K RPS is a failure... somewhere.

Pretty much matches my experience of Rust + Cassandra on a Linux laptop (I get ~250k req/s without database, ~50k with updates).

App Service will fail any benchmark you throw at it, which is why this guy will get a letter from Microsoft's lawyers pretty soon. Just like with Oracle Database, benchmarking the Azure Cloud is verboten, especially their PaaS services.

Azure App Service has a networking stack that I would categorise as a "hot pile of steaming garbage":

It is insanely, unbelievably, almost hilariously slow. Even internally they VPN-tunnel, they NAT, and then they then do some unnecessary L7 stuff. If you can talk to App service in under 3ms, then you're lucky.

Heaven help you if you've made the mistake of separating out an "API tier" or any such thing. Using Azure SQL Database is iffy also, but no worries, support will helpfully tell you how to improve your latency from an IaaS VM... which is not what you're using if you're using App Service.

We get 500 req /sec hitting a non trivial database load.

Reply on news.ycombinator.com