相關(guān)知識請參考.netCore開發(fā)團(tuán)隊(duì)博客 https://blogs.msdn.microsoft.com/dotnet/??

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

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

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

ReadyToRun圖像

托管應(yīng)用程序通?？赡芫哂休^差的啟動性能，因?yàn)槭紫缺仨殞IT編譯為機(jī)器代碼。.NET Framework具有預(yù)編譯技術(shù)NGEN。但是，NGEN需要在將執(zhí)行代碼的計(jì)算機(jī)上執(zhí)行預(yù)編譯步驟。對于Bing來說，這意味著NGENing成千上萬的機(jī)器。隨著應(yīng)用程序在Web服務(wù)機(jī)器上進(jìn)行預(yù)編譯，這與積極的部署周期相結(jié)合將導(dǎo)致顯著的服務(wù)容量減少。此外，運(yùn)行NGEN需要管理權(quán)限，這些權(quán)限在數(shù)據(jù)中心設(shè)置中通常不可用或經(jīng)過嚴(yán)格審查。在.NET Core上，crossgen 工具允許將代碼預(yù)編譯為預(yù)部署步驟，例如在構(gòu)建實(shí)驗(yàn)室中，并且部署到生產(chǎn)的映像已準(zhǔn)備好運(yùn)行！

性能

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

我們的生產(chǎn)數(shù)據(jù)與.NET Core 2.1中的顯著性能改進(jìn)（與.NET Core 2.0和.NET Framework 4.7.2相比）產(chǎn)生了共鳴。下圖跟蹤了過去幾個月內(nèi)部服務(wù)器的延遲情況。Y軸是延遲（省略實(shí)際值），最后的急劇下降（6月2日）是.NET Core 2.1的部署！這一切都提高了34％，這要?dú)w功于.NET社區(qū)的辛勤工作！

.NET Core 2.1中的以下更改是我們工作負(fù)載的顯著改進(jìn)的亮點(diǎn)。它們以降低的影響順序呈現(xiàn)。

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

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

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

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

軟件寫入監(jiān)視并發(fā)GC（@ Maoni0和@kouvel）

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

使用calli的方法現(xiàn)在可以內(nèi)聯(lián)（@AndyAyersMS和@mjsabby）

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

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

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

除了運(yùn)行時更改之外，.NET Core 2.1還為.NET庫生態(tài)系統(tǒng)帶來了Brotli支持。Bing.com使用此功能動態(tài)壓縮內(nèi)容并將其提供給支持的瀏覽器。

運(yùn)行時敏捷

最后，在我們的應(yīng)用程序中擁有運(yùn)行時的xcopy版本的能力意味著我們能夠以更快的速度采用更新版本的運(yùn)行時。事實(shí)上，如果您查看上面的圖表，我們將在6月2日（即發(fā)布后的兩天）的常規(guī)應(yīng)用程序部署中全球范圍內(nèi)進(jìn)行.NET Core 2.1更新！

這是可能的，因?yàn)槲覀冊?NET Core的每日CI構(gòu)建測試功能和性能的整個版本中運(yùn)行我們的持續(xù)集成（CI）管道。

我們對未來感到興奮，并與.NET團(tuán)隊(duì)密切合作，幫助他們確定未來的更新資格！.NET Core團(tuán)隊(duì)很興奮，因?yàn)槲覀兲峁┝舜罅康墓δ軠y試和額外的大型代碼庫來衡量實(shí)際的性能改進(jìn)，以及我們致力于為Bing.com用戶提供快速結(jié)果以及我們自己的開發(fā)人員使用最新的軟件和工具。

原文地址:?https://www.cnblogs.com/fancunwei/p/9509830.html

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的Bing.com在.NET Core 2.1上运行的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。