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
我建了個知識星球，希望能和更多的小伙伴交流，歡迎關注哦。