• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

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

开发技术 开发技术 1周前 (09-09) 19次浏览

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 进程内与进程外的性能对比

在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的方式有些相似。

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

此实现形式,应用会访问本机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 Core 进程内与进程外的性能对比

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

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

性能对比

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

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

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

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

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

进程内托管模式结果

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

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

进程外托管模式结果

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

切换为进程外后,一共处理了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

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


喜欢 (0)