ASP.NET Core 8 在 Windows 上各种部署模型的性能测试

我们知道 Asp.net Core 在 windows 服务器上部署的方案有 4 种之多。这些部署方案对性能的影响一直以来都是靠经验。比如如果是部署在 IIS 下，那么 In Process 会比 Out Process 快；如果是 Self Host 那么使用 HttpSys 服务器会比 Kestrel 快。
那么真实结果是否如我们想象的那样呢？接下来就让我们来做一次 benchmarks 吧。

托管模型

在开始 benchmark 测试之前，我们再来来介绍一下这 4 种托管模型：

1. InProcess 模式

InProcess 模式将 ASP.NET Core 应用程序直接部署在 IIS 中，与 IIS 工作进程相同的进程中运行。理论上，这种模式的性能应该相对较高，因为请求无需经过额外的进程通信。

2. OutProcess 模式

OutProcess 模式下，ASP.NET Core 应用程序在独立于 IIS 工作进程的进程中运行。这种模式通过进程间通信与 IIS 进行通信，理论上可能引入一些性能开销。

3. SelfHost HttpSys 模式

HttpSys 模式是一种自承载方式，利用 Windows 操作系统内核级的 HTTP 服务器。通常认为在处理大量并发连接时具有优势，因为它与操作系统集成。

4. SelfHost Kestrel 模式

Kestrel 模式是 ASP.NET Core 的内置 Web 服务器，可以独立运行而无需依赖其他外部服务器。Kestrel 是轻量级、跨平台的选择，专为处理大量并发连接而设计。

压测平台

• 操作系统: Windows Server 2012 R2 Datacenter
• 硬件配置: Intel E3 1260L CPU, 16GB 内存
• 网络: 家庭内网，TP-LINK 家用 1000M 交换机

因为本人没啥高性能的服务器，家里只有一台老旧的 HP Gen8 服务器。安装 windows server 2012 R2 datacenter，CPU 为 E3 1260L。E3 同样是古董，大概是 intel 10年前的产品。内存为 16G 1333 服务器专用内存。
整个测试平台可以说是相当拉跨。凑合用用吧，反正不是彪极限性能，横向对比的话问题不大。

压测过程

新建一个 ASP.NET Core 默认项目。采用 VS2022 自带的模板，使用 miniapi 对 '/' 路径直接输出 'Hello World!' 字符串。

using System.Diagnostics;  var builder = WebApplication.CreateBuilder(args);  // Add services to the container.  var app = builder.Build();  // Configure the HTTP request pipeline.  app.MapGet("/", () => {     return "Hello World!"; });  app.Run();  

如果使用 HttpSys 服务器则多加一行代码：

builder.WebHost.UseHttpSys(); 

• 测试工具: 使用 Netling 进行压力测试，模拟真实用户请求。
• 测试流程: 在对每个场景进行测试前先进行 60s 的预热，等待大概 10s 再后进行 4 次持续的压力测试（8个线程，持续30s），记录结果（RPS）。

Benchmark 测试结果

以下是测试结果：

性能分析与总结

测试结果大大的出乎了我的预料，特别是 OutProcess 模式的性能略高于 InProcess 模式，与我的认知出现了比较大的偏差。同时，SelfHost Kestrel 模式的性能优于 SelfHost HttpSys 模式，这也与一般的预期不同，因为 HttpSys 是运行在内核态的服务器。

这样的差异可能受多种因素影响，包括硬件配置、操作系统版本、IIS的版本等，毕竟这些产品都是10年前的产物，而 ASP.NET Core8 是 2023 年的全新产品。测试结果受到多种因素的影响，大家不要较真，就图一乐吧。

不过从结果上横向来看，至少可以得出以下结论：

• Self Host 比 IIS Host 性能上要快上好几倍。在追求极限性能的场景，应该选择 Self Host。
• IIS Host 不管是 In Process 还是 Out Process 性能也不差。就测试平台这种老古董也能跑个 7000+ RPS。这还不是极限，因为 7000 RPS 的时候 CPU 才到 50%+ 。如果我再多加一些线程，相信轻松可以过万。
• 以上最差的结果也有 7000 多的 RPS。这表明对于一般的信息系统而言，ASP.NET Core 本身的性能一般不会是瓶颈。瓶颈最早出现一定是在其他 IO 模块，比如数据库。