ASP.NET Core 进程内与进程外的性能对比
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了ASP.NET Core 进程内与进程外的性能对比，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4302字，纯文字阅读大概需要7分钟。
内容图文
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://github.com/RickStrahl/AspetCoreIISInprocessHostingSample
我建了个知识星球，希望能和更多的小伙伴交流，欢迎关注哦。
内容总结
以上是互联网集市为您收集整理的ASP.NET Core 进程内与进程外的性能对比全部内容，希望文章能够帮你解决ASP.NET Core 进程内与进程外的性能对比所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。