Pratik Bhattacharya
Pratik Bhattacharya

Reputation: 3746

Performance issues in running .NET Core APIs in Azure App Services for Linux

I tried porting some of my Web APIs built on .NET Core 3.1 to Azure App Services (on Linux). Earlier all these APIs were hosted in Azure App Services (on Windows), but I wanted to port to them to a Linux Environment, due to the huge cost benefits associated with them.

However after porting them and running some of the performance suites I found some serious performance difference between Linux and Windows App Service. I was expecting that performance in Linux App Service would either improve or remain the same, but to my dismay the performance actually degraded. Here are some of the results:

+-----------------------------------------------+-----------+--------+---------+
| Operation                                     | User Load | Linux  | Windows |
+-----------------------------------------------+-----------+--------+---------+
| Cosmos DB Read                                | 50        | 600 ms | 60 ms   |
+-----------------------------------------------+-----------+--------+---------+
| Simple Ping                                   | 50        | 30 ms  | 20 ms   |
+-----------------------------------------------+-----------+--------+---------+
| 15 parallel calls to Azure Feature Management | 50        | 510 ms | 160 ms  |
+-----------------------------------------------+-----------+--------+---------+

What is causing this performance degradation in Linux? Is it a .NET Core thing, where performance is better in Windows compared to Linux. If so, is this something that would get addresses in .NET 5 or other subsequent releases?

Upvotes: 3

Views: 1135

Answers (2)

sedat
sedat

Reputation: 9

I did the same thing and moved my ASP.Net core 2.1 app to Azure Linux App Service. The same app had been hosted on Azure Windows app service. And it is true that the performance is much worse than the Azure Windows app service hosting. Since we need two or more instances to meet the workload with the Linux option, we are planning to move back to Windows.

Check out this article. It says that with the Linux option the application is hosted out of process: https://www.uveta.io/categories/blog/windows-vs-linux-appservice-whats-the-difference/

Application will always run out of process, as opposed to in-process hosting. Even if using supported stack, i.e. .NET Core, it will still default to out of process hosting, under these circumstances. This can result in reduced throughput, especially if application is serving ample amounts of incoming requests.

Upvotes: 1

Noah Stahl
Noah Stahl

Reputation: 7553

For CosmosDB at least, there is a documented performance preference for Windows when using the .NET SDK:

We recommend Windows 64-bit host processing for improved performance. The SQL SDK includes a native ServiceInterop.dll to parse and optimize queries locally. ServiceInterop.dll is supported only on the Windows x64 platform. For Linux and other unsupported platforms where ServiceInterop.dll isn't available, an additional network call is made to the gateway to get the optimized query.

Upvotes: 3

Related Questions