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

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