Bing.com在.NET Core 2.1上運行！

Bing.com在.NET Core 2.1上運行！

 

相關知識請參考.netCore開發團隊博客(https://blogs.msdn.microsoft.com/dotnet/) 

Bing.com是一種雲服務，運行在遍布全球許多數據中心的數千台服務器上。Bing服務器每秒處理來自全球消費者的數千個用戶查詢，通過他們的瀏覽器，使用 Microsoft認知服務API的 合作伙伴以及個人數字助理Cortana進行搜索。我們的用戶要求這些結果具有相關性和速度，因此性能和可靠性是運行Bing等成功雲服務的關鍵組件。

Bing的前端堆棧主要是以MVC模式分層的托管代碼編寫的。大多數業務邏輯代碼都是用C＃編寫的數據模型，視圖邏輯是用 Razor 編寫的。該層負責將搜索結果數據（編碼為 Microsoft Bond ）轉換為HTML，然后將其壓縮並發送到瀏覽器。作為Bing的前端平台的守門人，我們將開發人員的工作效率和功能敏捷性視為我們成功定義中的附加關鍵組件。數以百計的開發人員依靠這個平台將他們的功能投入生產，他們希望它能像鍾表一樣運行。

從一開始，Bing.com就在.NET Framework上運行，但它最近已轉換為在.NET Core上運行。推動Bing.com采用.NET Core的主要原因是性能（即服務延遲），支持並行和應用程序本地安裝，與機器范圍的安裝（或缺少安裝）和 ReadyToRun映像無關 。為了實現這些改進，我們開始努力使代碼在.NET實現中可移植，而不是依賴於僅在Windows上可用且僅與.NET Framework一起使用的庫。團隊開始使用.NET Standard 1.x，但是減少的API表面為我們的代碼遷移帶來了非常重要的復雜性。使用 .NET Standard 2.0 返回的20,000多個API，一切都改變了，我們能夠迅速從代碼修改轉移到測試。在壓縮了一些bug后，我們准備將.NET Core部署到生產環境中。

ReadyToRun圖像

托管應用程序通常可能具有較差的啟動性能，因為首先必須將JIT編譯為機器代碼。.NET Framework具有預編譯技術 NGEN 。但是， NGEN 需要在將執行代碼的計算機上執行預編譯步驟。對於Bing來說，這意味着 NGENing 成千上萬的機器。隨着應用程序在Web服務機器上進行預編譯，這與積極的部署周期相結合將導致顯着的服務容量減少。此外，運行 NGEN 需要管理權限，這些權限在數據中心設置中通常不可用或經過嚴格審查。在.NET Core上， crossgen 工具允許將代碼預編譯為預部署步驟，例如在構建實驗室中，並且部署到生產的映像已准備好運行！

性能

.NET Core 2.1幾乎在運行時和庫的所有領域都進行了重大的性能改進; 博客 上一篇文章中提供了一篇很好的論文。

我們的生產數據與.NET Core 2.1中的顯着性能改進（與.NET Core 2.0和.NET Framework 4.7.2相比）產生了共鳴。下圖跟蹤了過去幾個月內部服務器的延遲情況。Y軸是延遲（省略實際值），最后的急劇下降（6月2日）是.NET Core 2.1的部署！這一切都 提高 了 34％ ，這要歸功於.NET社區的辛勤工作！

.NET Core 2.1中的以下更改是我們工作負載的顯着改進的亮點。它們以降低的影響順序呈現。

1. 矢量化string.Equals（@jkotas）和string.IndexOf/LastIndexOf（@eerhardt）

無論您采用哪種方式切片，HTML渲染和操作都是字符串繁重的工作負載。字符串比較和索引操作是其中的主要組成部分。這些操作的矢量化是我們測量的性能改進的最大貢獻者。

1. EqualityComparer<T>.Default（@AndyAyersMS）的虛擬化支持

我們的主要軟件組件之一是重度用戶 Dictionary<int/long, V> ，間接受益於JIT中為了 Dictionary<K, V>優化 而進行的內在識別工作（@benaadams）

1. 軟件寫入監視並發GC（@ Maoni0和@kouvel）

這導致我們的應用程序中CPU使用率降低。在.NET Core 2.1之前，Windows x64（以及.NET Framework）上的寫入監視是使用具有不同性能權衡的Windows API實現的。這個新實現依賴於JIT寫屏障，它直觀地增加了參考商店的成本，但是這個成本是攤銷的，而且在我們的工作量中沒有注意到。此改進現在也可以通過 2018年5月的安全性和質量匯總 在.NET Framework上獲得

1. 使用calli的方法現在可以內聯（@AndyAyersMS和@mjsabby）

我們在代碼的性能關鍵部分中使用 ldftn + calli 代替委托（這會產生對象分配），其中需要間接調用托管方法。此更改允許具有 calli 指令的方法體具有內聯條件。我們的依賴注入框架生成這樣的方法

1. 提高string.IndexOfAny的2＆3 char搜索性能（@bbowyersmyth）

前端堆棧中的常見操作是在字符串中搜索“：”，“/”，“/”以分隔URL的各個部分。這種特殊的外殼改進在整個代碼庫中都是有益的。

除了運行時更改之外，.NET Core 2.1還為.NET庫生態系統帶來了 Brotli 支持。Bing.com使用此功能動態壓縮內容並將其提供給支持的瀏覽器。

運行時敏捷

最后，在我們的應用程序中擁有運行時的xcopy版本的能力意味着我們能夠以更快的速度采用更新版本的運行時。事實上，如果您查看上面的圖表，我們將在6月2日（即發布后的 兩天） 的常規應用程序部署中全球范圍內進行.NET Core 2.1更新！

這是可能的，因為我們在.NET Core的每日CI構建測試功能和性能的整個版本中運行我們的持續集成（CI）管道。

我們對未來感到興奮，並與.NET團隊密切合作，幫助他們確定未來的更新資格！.NET Core團隊很興奮，因為我們提供了大量的功能測試和額外的大型代碼庫來衡量實際的性能改進，以及我們致力於為Bing.com用戶提供快速結果以及我們自己的開發人員使用最新的軟件和工具。

本篇文章原址：Bing.com runs on .NET Core 2.1!