ASP.NET Core 进程内与进程外的性能对比

ASP.NET Core 进程内与进程外的性能对比

本文内容是《深入去浅出ASP.NET Core》提供的扩展内容，毕竟在书里说进程内外的性能说明对比，对于初学者而言，稍微复杂了点。

我在B站的视频是基于.NET Core 2.2提供的案例，在书籍中提供的是.NET Core 3.1的案例。有人问，默认进程到底是进程外还是进程内。

ASP.NET Core 默认进程

ASP.NET Core 2.2 由默认的进程外，所以需要我们指定下项目文件中的进程信息。
而从ASP.NET Core 3.X开始，dotnet开发团队又将它修改为了进程内。

所以请记住：

• ASP.NET Core 2.X及以前默认是进程外托管
• ASP.NET Core 3.X默认为进程内托管

我最近查询了下，应该说最早.NET Core就不支持进程内，所以也是慢慢迭代到支持进程内的。

ASP.NET Core的进程内托管

使用 InProcess 托管，应用程序托管在 IIS 工作进程(w3wp.exe 或 iisexpress.exe)中。 只有一个 Web 服务器，它是承载我们的应用程序的 IIS 服务器,如图是进程内托管图。

在ASP.NET Core 2.2后，IIS上有了一个In Process托管模型，该模型直接在IIS应用程序池内部托管ASP.NET Core，而无需使用代理dotnet.exe运行.NET Core本机Kestrel Web服务器的外部实例。

进程内模型不使用Kestrel，而是使用IISHttpServer()直接在IIS应用程序池内部托管的新Web服务器实现，该实现与传统的ASP.NET被引入IIS的方式有些相似。

此实现形式，应用会访问本机IIS对象以建立创建的请求数据，并将HttpContext其传递到ASP.NET Core中间件管道。

当然这些都是.NET Core层面的处理，我们作为应用开发者，基本会去关心和留意它。

但是就是这个调整，大大的提高了ASP.NET Core在IIS上的请求吞吐量。

实际生产环境中InProces还是OutOfProcess

对于部署项目到IIS环境中，您几乎肯定希望是采用InProcess模式进行托管，因为它提供了更好的性能，并且通常占用的资源较少，因为它避免了IIS和Kestrel之间可能存在的网络抖动。

但是是其他场景下，我就推荐采用OutOfProcess模式了，比如：

• 用于故障排除和调试故障服务器（例如，您可以在启用控制台日志记录,查看更加详细的信息）。
• 同一个应用程序实现100％兼容，无论是部署在Windows还是Linux上，Kestrel的主要机制是可以处理所有平台上的HTTP请求。
• 使用InProcess模型时，则不会使用Kestrel服务(这个在我的书中有详细说明)，而是直接与IIS的请求管道中的模块进行通信。

调整为进程外托管

我们可以通过修改项目文件，配置AspNetCoreHostingModel值以下

<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel >

然后就可以调整为进程外托管模式。

关于更多进程内和进程外的知识，可以查看《深入浅出ASP.NET Core》的5.4章内容。

West Wind WebSurge 测试

我准备了一个项目Demo，使用 West Wind WebSurge 软件来测试下进程内与进程外项目的吞吐情况。

它还可以检查服务器的HTTP响应，并检查Web服务器Kestrel或Microsoft IIS作为Web服务器：

ASP.NET Core2.X 进程外(OutOfProcess)

ASP.NET Core2.X 进程内(Inprocess)

性能对比

使用新的In Process模型的明显原因是它更快，使用的资源更少，因为它直接在IIS应用程序池的过程中运行。没有内部HTTP流量和开销，请求将立即处理。

本次测试，仅仅是为了对比进程内核进程外的性能对比，不作为其他应用程序的抗负载能力的参考。

因为访问的接口很简单，请求仅表明可以大大提高潜在的吞吐量，但是对于长流程的请求和请求访问时间，应用程序处理的开销也增加，所以理性看待。

寻求高的性能始终是一个好主意，提供程序的吞吐量意味着更少的请求延迟，更快的响应时间以及更少的服务器开销，增加更多的负载能力。

我准备了一台4核8G的笔记本，因为这台笔记本装了很多其他应用，因此产生的结果肯定不如服务器的结果，现在开始进行测试。

进程内托管模式结果

上面的进程内托管模式，我们可以看到一共发送了3.7W次请求，每秒633次请求的处理速度。

进程外托管模式结果

切换为进程外后，一共处理了1.3W次请求，每秒是217次请求处理速度。

可以看到进程外的性能比进程内的较低。

再次说明，因为我的PC机中安装了和运行了大量的其他应用，给予它测试的内存和CPU是不足够的，感兴趣的可以，自己进行测试。

最后

尽管IIS被不停的边缘化以支持在Linux和Docker上托管，但请记住，如果发布到
云原生平台，如Azure的WebAPP或者其他未明确指定的平台，IIS依然是ASP.NET Core 部署的默认模型。这说明IIS确实还在很多场景中有广泛的使用，因此它不会很快消失。微软通过新增的进程内模型，提供更好的性能处理机制以此来增加对它的支持。

现在开始，我们有两种选择，

• 可以使用OutofProcessing（通过IIS代理请求）并使用完全独立的ASP.NET Core控制台应用程序（通过基于.NET的Kestrel Web服务器使用）托管在IIS上，
• 也可以使用InProcess托管模型，它与经典ASP.NET通过其自身的本机API与IIS进行交互的方式更为相似。
• In Process模型在请求吞吐量方面要快得多，因此在几乎所有情况下，在IIS上托管时，您都希望选择InProcess模型。

文章参考来源：https://weblog.west-wind.com/posts/2019/Mar/16/ASPNET-Core-Hosting-on-IIS-with-ASPNET-Core-22#check-the-response-server-header

案例源代码地址：https://github.com/RickStrahl/AspetCoreIISInprocessHostingSample

我建了个知识星球，希望能和更多的小伙伴交流，欢迎关注哦。