4 ms·

SRE here who deals with .Net (Core). If you have .Net and not running on Linux, you are just subjecting yourself to pain for no reason. .Net recommended runtime

SRE here who deals with .Net (Core). If you have .Net and not running on Linux, you are just subjecting yourself to pain for no reason. .Net recommended runtime environment is Linux, preferable a container, otherwise, I'd recommended Ubuntu LTS.

p_ing 2y ago
This depends on your requirements. If you want high performance non-blocking async networking, Windows is the better bet with .NET.
- stackskipton 2y ago
  Dude, just wrong. Last job, we moved .Net RabbitMQ job processor that was making a bunch of async web calls nightly would handle 50k+ messages from Windows to Linux, our job processing time was cut by 2/3. In fact, first few mornings, no one believe the execution time, thought it had silently failed and Dev team manually checked it it's work. Nope, it did its job properly with less RAM/CPU. You can see some benchmarks here FROM 2017: https://robertoprevato.github.io/Comparing-Linux-hosted-to-Windows-hosted-ASP-NET-Core-applications-in-Azure-Application-Service-Plan/ https://robertoprevato.github.io/Comparing-Linux-hosted-to-W... where Linux is beating out Windows in Async web workloads. That's only gotten better since years have gone on. In my personal experience dealing with .Net 6+ (Mostly 8 now), Linux destroys Windows in performance running .Net workloads hands down 95% of the time. This lines up with Microsoft .Net team advice, every time the topic comes up "Windows or Linux?" They say "Linux, it's easier to deal with and performance is better."
- neonsunset 2y ago
  .NET has really good integration between async and networking via epoll/kqueue-based Socket (SocketAsyncEngine) implementation. Given that Linux is the main target for server workloads written in C# or F# nowadays, it has better or more uniform performance more often than not. My experience aligns with sibling comment by stackskipton.
  - p_ing 2y ago
    epoll and kqueue are userland mechanisms for async that aren't non-blocking async I/O in the kernel.
    - neonsunset 2y ago
      What do you think the kernel is doing? :) I'm really not sure why you are arguing in favour of using Windows Server. This is legitimately bad advice. ASP.NET Core team maintains an extensive suite of benchmarks. If you select plaintext or fortunes or json for Intel Gold Linux and Windows (both Kestrel and IIS) hosts, you will see that pure Kestrel with Linux has the best throughput and latency across the board. https://msit.powerbi.com/view?r=eyJrIjoiYTZjMTk3YjEtMzQ3Yi00NTI5LTg5ZDItNmUyMGRlOTkwMGRlIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9&pageName=ReportSection30725cd056a647733762&pageName=ReportSection30725cd056a647733762 https://msit.powerbi.com/view?r=eyJrIjoiYTZjMTk3YjEtMzQ3Yi00...
      - bob1029 2y ago
        The difference is actually quite shocking to me. I wasn't expecting it to be that extreme. I would say that Kestrel is so damn fast it probably doesn't matter much either way. I've only ever used it on Windows and it hasn't disappointed.
neonsunset 2y ago
To be fair, ASP.NET Core has pretty nice http.sys integration for IIS. I'm an advocate of running such workloads on Linux whenever possible too, but I wouldn't say that IIS is that bad, but it is definitely worse. On the topic, please stop putting Nginx in front of Kestrel just for the sake of it (i.e. you have a single node, or it's an internal network without a load-balancer, etc.) - you're literally wasting resources on additional point of failure and more network hops.
- stackskipton 2y ago
  We do it on Single node just because doing HTTPS with Kestrel in a container is painful. Volume mounting the config file + certificates along with Kestrel appsettings.json is annoying vs Proxy server which makes it much easier.
  - neonsunset 2y ago
    You can use ConfigMap instead of volume for providing the config (it is also nice since you can merge the application settings with the deployment manifest). For certificates, you can retrieve them from whatever vault solution you have on hand, or you can, indeed, access a volume. I do not understand the difficulties with volume mounting however which is a standard practice. Configuring Kestrel programmatically is really straightforward too: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/endpoints?view=aspnetcore-9.0#configure-https-in-code https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s... I'm not saying just using Nginx is a bad choice, but, much like using Redis for things that have no business using Redis, I've seen a fair share of the same misuse with Nginx.
    - stackskipton 2y ago
      If you have ConfigMap, you have Kubernetes so Ingress is solved for you. ;) > Configuring Kestrel programmatically is really straightforward too Sure, but Developers tend to not want to futz with it. My use case is our application lives in a container, most of time we host it but occasionally a customer demands they host it so we give them the container. Some host it on Windows (we do build a Windows container of our application :vomit:) and some on Linux. In any case, we require them to use reverse proxy because HTTPS with Kestrel was becoming too high of support so we require they provide HTTPS proxy. We recommend IIS ARR for Windows users, and CaddyServer for Linux but Linux users tend to not need our advice. EDIT: Our hosting platform is Azure Kubernetes Service, 100% Linux Nodes.

p_ing 2y ago

This depends on your requirements. If you want high performance non-blocking async networking, Windows is the better bet with .NET.

stackskipton 2y ago
Dude, just wrong. Last job, we moved .Net RabbitMQ job processor that was making a bunch of async web calls nightly would handle 50k+ messages from Windows to Linux, our job processing time was cut by 2/3. In fact, first few mornings, no one believe the execution time, thought it had silently failed and Dev team manually checked it it's work. Nope, it did its job properly with less RAM/CPU. You can see some benchmarks here FROM 2017: https://robertoprevato.github.io/Comparing-Linux-hosted-to-Windows-hosted-ASP-NET-Core-applications-in-Azure-Application-Service-Plan/ https://robertoprevato.github.io/Comparing-Linux-hosted-to-W... where Linux is beating out Windows in Async web workloads. That's only gotten better since years have gone on. In my personal experience dealing with .Net 6+ (Mostly 8 now), Linux destroys Windows in performance running .Net workloads hands down 95% of the time. This lines up with Microsoft .Net team advice, every time the topic comes up "Windows or Linux?" They say "Linux, it's easier to deal with and performance is better."
neonsunset 2y ago
.NET has really good integration between async and networking via epoll/kqueue-based Socket (SocketAsyncEngine) implementation. Given that Linux is the main target for server workloads written in C# or F# nowadays, it has better or more uniform performance more often than not. My experience aligns with sibling comment by stackskipton.
- p_ing 2y ago
  epoll and kqueue are userland mechanisms for async that aren't non-blocking async I/O in the kernel.
  - neonsunset 2y ago
    What do you think the kernel is doing? :) I'm really not sure why you are arguing in favour of using Windows Server. This is legitimately bad advice. ASP.NET Core team maintains an extensive suite of benchmarks. If you select plaintext or fortunes or json for Intel Gold Linux and Windows (both Kestrel and IIS) hosts, you will see that pure Kestrel with Linux has the best throughput and latency across the board. https://msit.powerbi.com/view?r=eyJrIjoiYTZjMTk3YjEtMzQ3Yi00NTI5LTg5ZDItNmUyMGRlOTkwMGRlIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9&pageName=ReportSection30725cd056a647733762&pageName=ReportSection30725cd056a647733762 https://msit.powerbi.com/view?r=eyJrIjoiYTZjMTk3YjEtMzQ3Yi00...
    - bob1029 2y ago
      The difference is actually quite shocking to me. I wasn't expecting it to be that extreme. I would say that Kestrel is so damn fast it probably doesn't matter much either way. I've only ever used it on Windows and it hasn't disappointed.

neonsunset 2y ago

To be fair, ASP.NET Core has pretty nice http.sys integration for IIS. I'm an advocate of running such workloads on Linux whenever possible too, but I wouldn't say that IIS is that bad, but it is definitely worse. On the topic, please stop putting Nginx in front of Kestrel just for the sake of it (i.e. you have a single node, or it's an internal network without a load-balancer, etc.) - you're literally wasting resources on additional point of failure and more network hops.

stackskipton 2y ago
We do it on Single node just because doing HTTPS with Kestrel in a container is painful. Volume mounting the config file + certificates along with Kestrel appsettings.json is annoying vs Proxy server which makes it much easier.
- neonsunset 2y ago
  You can use ConfigMap instead of volume for providing the config (it is also nice since you can merge the application settings with the deployment manifest). For certificates, you can retrieve them from whatever vault solution you have on hand, or you can, indeed, access a volume. I do not understand the difficulties with volume mounting however which is a standard practice. Configuring Kestrel programmatically is really straightforward too: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/endpoints?view=aspnetcore-9.0#configure-https-in-code https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s... I'm not saying just using Nginx is a bad choice, but, much like using Redis for things that have no business using Redis, I've seen a fair share of the same misuse with Nginx.
  - stackskipton 2y ago
    If you have ConfigMap, you have Kubernetes so Ingress is solved for you. ;) > Configuring Kestrel programmatically is really straightforward too Sure, but Developers tend to not want to futz with it. My use case is our application lives in a container, most of time we host it but occasionally a customer demands they host it so we give them the container. Some host it on Windows (we do build a Windows container of our application :vomit:) and some on Linux. In any case, we require them to use reverse proxy because HTTPS with Kestrel was becoming too high of support so we require they provide HTTPS proxy. We recommend IIS ARR for Windows users, and CaddyServer for Linux but Linux users tend to not need our advice. EDIT: Our hosting platform is Azure Kubernetes Service, 100% Linux Nodes.