我的 .NET Core 博客性能优化经验总结
點(diǎn)擊上方藍(lán)字關(guān)注“汪宇杰博客”
導(dǎo)語
去年8月，我用 .NET Core 重寫了我的博客系統(tǒng)。經(jīng)過一年多的優(yōu)化，服務(wù)器響應(yīng)速度從上線時(shí)候的 80ms 提高到了現(xiàn)在的 8ms，十倍提速。可惜由于部署在國外，自然不可抗力會(huì)導(dǎo)致中國用戶晚上訪問速度不穩(wěn)定。本文分享網(wǎng)絡(luò)正常的前提下，我做了哪些優(yōu)化和提升，希望能幫到大家。
其實(shí)，在.NET Core之前，我的舊版博客系統(tǒng)是 .NET Framework寫的，從2008年的 ASP.NET Web From 2.0 一直維護(hù)到2018年的 ASP.NET MVC5，曾經(jīng)被人懷疑過：“別騙人了，.NET怎么可能這么快？” 。而如今，.NET Core 從本質(zhì)上就已經(jīng)比 .NET Framework 有了巨大的性能提升，甚至在不少測試下超過了Node、Go、Java。其實(shí)光看 benchmark 沒太大的意義，大部分實(shí)際應(yīng)用中性能問題并不在于語言和框架，而是由不佳的設(shè)計(jì)、錯(cuò)誤的框架使用方法引起的。在 .NET Core 的實(shí)踐過程中，我也學(xué)習(xí)和收獲了很多，因此寫下此文，分享我自己的性能優(yōu)化經(jīng)驗(yàn)。
沒有銀彈
首先，每個(gè)系統(tǒng)都是不同的。性能優(yōu)化需要針對不同系統(tǒng)，不同業(yè)務(wù)場景，不同應(yīng)用領(lǐng)域，不同用戶種群，沒有一個(gè)通用方法。比如我的博客，是內(nèi)容站，交互少，大量情況都是各種姿勢讀數(shù)據(jù)，所以我要保證的是盡可能快的提升數(shù)據(jù)讀取速度。而有些系統(tǒng)，比如電商，有遠(yuǎn)比內(nèi)容站復(fù)雜的業(yè)務(wù)邏輯，還有秒殺等極端情況。比如國內(nèi)阿里帶隊(duì)的“數(shù)據(jù)庫不要有外鍵”，這是因?yàn)榘⒗锏臉I(yè)務(wù)壓力必須這么做，他們需要的是極端情況的寫入速度，顯然我的博客以及很多內(nèi)容站沒有這種場景，因此我依然可以用外鍵。所以，在開始之前，讀者必須明白，軟件設(shè)計(jì)是沒有銀彈的。我所列出的經(jīng)驗(yàn)僅僅針對我自己的博客。大部分經(jīng)驗(yàn)?zāi)軕?yīng)用在類似的內(nèi)容站上，但不要盲目實(shí)踐。同樣是內(nèi)容站，面對的用戶群和壓力也不一樣，比如我的博客肯定無法和新浪、網(wǎng)易等比流量，所以優(yōu)化的關(guān)鍵點(diǎn)和方法也不同。
分析和發(fā)現(xiàn)關(guān)鍵點(diǎn)
雖然我們在系統(tǒng)設(shè)計(jì)時(shí)會(huì)有一定的預(yù)判，比如哪些功能是用戶最常用的，哪些請求會(huì)是最頻繁的。但是上線之后用戶的行為才是事實(shí)，有時(shí)候系統(tǒng)的表現(xiàn)會(huì)和我們的預(yù)期不一樣。而且，隨著時(shí)間的推移，用戶的使用習(xí)慣可能會(huì)變，系統(tǒng)面臨壓力的部分也會(huì)改變。所以，我們需要記錄和分析系統(tǒng)在實(shí)際使用過程中產(chǎn)生的數(shù)據(jù)和用戶行為。而我所使用的Azure Application Insights就是一款極佳的APM工具。作為一個(gè)網(wǎng)站，性能是服務(wù)端（后臺(tái)）和客戶端（前臺(tái)）共同決定的，Azure Application Insights可以同時(shí)收集后端API處理速度、數(shù)據(jù)庫查詢相應(yīng)速度以及前端頁面資源加載速度、JS執(zhí)行速度等，也會(huì)自動(dòng)分析出最慢的請求是哪些，系統(tǒng)最耗時(shí)的操作在哪個(gè)環(huán)節(jié)（前端、程序或數(shù)據(jù)庫），甚至Azure SQL Database能根據(jù)實(shí)際使用情況自動(dòng)推薦優(yōu)化方案（比如哪里加何種索引等）。本文不討論APM工具的使用。但是做性能優(yōu)化的時(shí)候，必須針對實(shí)際用戶產(chǎn)生的數(shù)據(jù)，分析以后去鑒別哪里需要優(yōu)化。我的博客上線幾個(gè)月后，我的分析如下：
1.?????? 客戶端性能開銷在加載資源和過多的請求（前端庫，博客文章配圖）
2.?????? 服務(wù)端性能開銷在過多重復(fù)的SQL查詢
3.?????? 博客配圖由后端從Azure Blob Storage中讀取再返回前端產(chǎn)生雙倍性能開銷
前端實(shí)踐
使用 bundle 避免過多請求
我相信大部分Web程序員都熟悉這一條建議，這也是最直接有效的前端性能提升方式。我們網(wǎng)站中通常要加載許多不同的庫和資源，有圖片，CSS，JS等。而瀏覽器大量的時(shí)間開銷在于對這些資源發(fā)起請求，等待響應(yīng)。即使你的文件很小，但是太多的請求數(shù)量會(huì)明顯降低網(wǎng)頁加載速度。因此很久之前業(yè)界就流行一種做法，即打包壓縮資源文件，比如將多個(gè)JS文件打包壓縮成一份，這樣瀏覽器就只要發(fā)起一個(gè)請求，就能加載你網(wǎng)站所有需要的JS資源。
打包工具五花八門，可以根據(jù)自己的喜好選擇。我博客使用的是 BuildBundlerMinifier，它可以在編程和編譯時(shí)完成打包：
<PackageReference Include="BuildBundlerMinifier" Version="3.2.435" />
其定義示例如下：
{
? "outputFileName": "wwwroot/js/app/app-js-bundle.js",
? "inputFiles": [
??? "wwwroot/lib/jquery/jquery.min.js",
??? "wwwroot/lib/jquery-validate/jquery.validate.min.js",
??? "wwwroot/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js",
??? "wwwroot/lib/twitter-bootstrap/js/bootstrap.bundle.min.js",
??? "wwwroot/lib/jquery-qrcode/jquery.qrcode.min.js",
??? "wwwroot/lib/toastr.js/toastr.min.js",
??? "wwwroot/js/lazyload.js",
??? "wwwroot/js/app/moonglade-base.js",
??? "wwwroot/js/app/postslug.js",
??? "wwwroot/js/app/csrf.js",
??? "wwwroot/js/app/comments.js"
? ]
}
Js真的要放body最后嗎？
這也是一條幾乎Web程序員人盡皆知的原則。如果你將JS資源放在body最后加載，即</body>標(biāo)簽之前，那么瀏覽器會(huì)異步加載你的JS。如果按照傳統(tǒng)方式將JS資源放在head標(biāo)簽里，那么瀏覽器必須加載完JS資源才開始渲染網(wǎng)頁。
聰明的朋友可能了解，這一條在2019年已經(jīng)不一定適用了。首先，我們可以通過添加defer標(biāo)簽來告訴瀏覽器，遇到這個(gè)JS，不要等加載完成再繼續(xù)干活，你管你渲染網(wǎng)頁，我管我加載：
<script defer src="996.js"></script>
<script defer src="007.js"></script>
不過defer的腳本還是會(huì)按順序執(zhí)行，這對于有依賴關(guān)系的JS資源十分重要，比如上面這段代碼，即使007.js非常小，首先加載完成，它也必須等到996.js加載完成后才能執(zhí)行。如果你想要誰先加載完，誰先執(zhí)行的效果，把defer換成async即可，這種情況下你得保證你的JS之間沒有依賴關(guān)系，沒有依賴關(guān)系，沒有依賴關(guān)系！！！重要的說三遍！
可惜，由于我們控制不了用戶使用的瀏覽器類型和版本，根據(jù) Azure Application Insights 的后臺(tái)統(tǒng)計(jì)，仍然有不少用戶使用低版本的瀏覽器訪問我的網(wǎng)站，它們并不認(rèn)識 defer和 async。
所以目前，我博客的實(shí)踐依然是JS盡量放body最后，但不是絕對！由于框架性質(zhì)的JS文件必須完成加載才能正確渲染網(wǎng)頁，因此我博客中它們還是放在head里，而用戶代碼我會(huì)放在body最后。優(yōu)化性能的前提，一定是不要影響正常功能！所以，程序員看問題不要非黑即白，還是那句軟件工程的老話：沒有銀彈。
如果你的網(wǎng)站沒有低版本的客戶端，那么可以盡量用 defer和 async。
使用 HTTP/2
啟用HTTP2可以有效提高網(wǎng)絡(luò)傳輸效率，根據(jù)該項(xiàng)調(diào)研（https://w3techs.com/technologies/details/ce-http2），截至2019年12月，全球大約有42.6%的網(wǎng)站已經(jīng)升級到了HTTP2。其對于網(wǎng)絡(luò)性能的提升主要在這幾個(gè)方面：
降低延遲以提高網(wǎng)頁加載速度：
HTTP頭的數(shù)據(jù)壓縮
服務(wù)器端推送 （這個(gè).NET Core好像沒有）
請求管線
修復(fù)HTTP 1.x中head-of-line blocking?的問題
同一個(gè)TCP連接上的請求多路復(fù)用
（參考：https://en.wikipedia.org/wiki/HTTP/2）
而我的博客使用微軟 Azure ?App Service 托管，可以點(diǎn)點(diǎn)鼠標(biāo)一秒切換到 HTTP/2，而不用自己996收福報(bào)：
如果你沒有用 Azure，也不用擔(dān)心，最新版 .NET Core 3.1 的kestrel 默認(rèn)就打開了HTTP/2:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#http2-support
使用壓縮
開啟服務(wù)器端response壓縮可以減小資源傳輸?shù)捏w積，從而達(dá)到提升性能的目的。使用 ASP.NET Core 開發(fā)的網(wǎng)站，部署在Azure上默認(rèn)就會(huì)開啟gzip，不需要自己996去研究。我的博客采用的 App Service Plan 是 Windows Server 2016，上面的IIS啟用了靜態(tài)和動(dòng)態(tài)資源壓縮。
然而，如果你不幸沒有使用 Azure，那么自己稍微996一下，在IIS上開啟壓縮也不難，可以點(diǎn)點(diǎn)鼠標(biāo)就搞定，也可以通過Web.config開啟（.NET Core部署在IIS下也認(rèn)web.config），具體方法可以參考：https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httpcompression/??
如果你用的不是IIS，也沒關(guān)系，再996一下，.NET Core自己也可以加response壓縮：
https://docs.microsoft.com/en-us/aspnet/core/performance/response-compression?view=aspnetcore-3.1
真的要用SPA嗎？
2014年以后，隨著SPA的興起，Angular等框架逐漸成為了前端開發(fā)的主流。它們解決的問題正是提升前端的響應(yīng)度，讓W(xué)eb應(yīng)用盡量接近本地原生應(yīng)用的體驗(yàn)。我也遇到過不少朋友有疑問，為啥我的博客不用angular寫？是我不會(huì)嗎？
其實(shí)并不那么簡單。實(shí)際上我在公司的主要工作目前也是寫angular，博客曾經(jīng)的.NET Framework版的后臺(tái)也用過angularjs以及angular2，經(jīng)過一系列的實(shí)踐表明，我博客這樣的內(nèi)容站用angular收益并不大。
其實(shí)這并不奇怪，在盲目選擇框架之前，我們得注意一個(gè)前提條件：SPA框架所針對的，其實(shí)是Web應(yīng)用。而應(yīng)用的意思是重交互，即像Azure Portal或Outlook郵箱那樣，目的是把網(wǎng)頁當(dāng)應(yīng)用程來開發(fā)，這時(shí)候SPA不僅能提升用戶體驗(yàn)，也能降低開發(fā)成本，何樂而不為？但是博客屬于內(nèi)容為主的網(wǎng)站，不是應(yīng)用，要說應(yīng)用也勉強(qiáng)只能說博客的后臺(tái)管理可以是應(yīng)用。博客前臺(tái)唯一的交互就是評論、搜索，因此SPA并不適合這樣的工作。這就像你要去菜場買菜，騎自行車反而比你開個(gè)坦克過去方便。
所以，程序員切記，看待問題不要非黑即白，不要覺得什么流行就一定適合所有項(xiàng)目，還是那個(gè)著名的軟件工程原則：沒有銀彈！
在微軟官方文檔里也有同樣的關(guān)于何時(shí)選擇SPA，何時(shí)選擇傳統(tǒng)網(wǎng)站的參考：
https://docs.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/choose-between-traditional-web-and-single-page-apps?
“
You should use traditional web applications when:
Your application's client-side requirements are simple or even read-only.
Your application needs to function in browsers without JavaScript support.
Your team is unfamiliar with JavaScript or TypeScript development techniques.
You should use a SPA when:
Your application must expose a rich user interface with many features.
Your team is familiar with JavaScript and/or TypeScript development.
Your application must already expose an API for other (internal or public) clients.
后端實(shí)踐
盡量避免Exception
.NET的Exception是一種特殊的類型，不管用戶代碼是否處理exception，只要產(chǎn)生，就會(huì)在CLR上有開銷。所以盡量避免產(chǎn)生Exception，尤其是不要利用Exception控制程序流程，這一點(diǎn)通常在.NET的技術(shù)文章里都會(huì)提及。一個(gè)不正常利用Exception的例子是我曾經(jīng)在公司代碼里看見過類似這樣判斷輸入的內(nèi)容是否為數(shù)字的代碼：
try
{???? ???????
????? Convert.ToInt32(userInput);
????? return true;
}
catch (Exception ex)
{
????? return false;
}
而.NET其實(shí)可以這樣寫：
int.TryParse(userInput);
我相信大部分正常的.NET程序員都不會(huì)犯上面這種錯(cuò)誤。這樣的代碼效率低下且不說，還容易炸毀IIS。IIS的應(yīng)用程序池如果在短時(shí)間檢測到大量CLR異常就會(huì)自爆重啟并返回503，中斷你的網(wǎng)站服務(wù)。
不過關(guān)于Exception的另一個(gè)爭論點(diǎn)在于，是否需要為業(yè)務(wù)異常設(shè)計(jì)自己的Exception類型？也就是檢查到非正常業(yè)務(wù)行為，到底返回Error Code還是直接拋出Exception再由上層處理？關(guān)于這點(diǎn)，我也沒有確定的結(jié)論。目前我的實(shí)踐是，僅對于非法輸入拋出參數(shù)異常，業(yè)務(wù)上的錯(cuò)誤不拋異常，例如文章被和諧后產(chǎn)生的404，不去設(shè)計(jì)比如 PostNotFoundException，這一點(diǎn)很關(guān)鍵，因?yàn)榻?jīng)常有無聊黑客新手使用自動(dòng)化工具掃描我的博客是否有漏洞，而這些工具會(huì)批量請求例如wp-login.php之類的對于我博客來說不存在的資源，如果我設(shè)計(jì)成拋出Exception再返回404，那么會(huì)造成短時(shí)間內(nèi)CLR上大量的異常，絕對會(huì)爆。
參考：https://devblogs.microsoft.com/cbrumme/the-exception-model/ 中“Performance and Trends”一節(jié)。
EF盡量使用AsNoTracking篩選只讀數(shù)據(jù)
每個(gè).NET群，都可以為Entity Framework vs Dapper吵一天。其實(shí)EF雖然在很多場景由局限，但并不那么差，只是想要用對，不產(chǎn)生性能問題，付出的學(xué)習(xí)成本相當(dāng)高。但是既然入坑了，就最好把它用用對。而最常見的情況就是遇到只讀數(shù)據(jù)，可以加上AsNoTracking()。我博客大部分的場景都是只讀數(shù)據(jù)，并且讀取后直接處理好關(guān)聯(lián)數(shù)據(jù)（Include），因此可以使用AsNoTracking()來斷開EF對于對象的追蹤，節(jié)省內(nèi)存也提高性能。為了不每次手寫AsNoTracking() 導(dǎo)致996，我在博客的存儲(chǔ)層直接設(shè)置了默認(rèn)參數(shù)：
public IReadOnlyList<T> Get(ISpecification<T> spec, bool asNoTracking = true)
{
??? return asNoTracking ?
??????? ApplySpecification(spec).AsNoTracking().ToList() :
??????? ApplySpecification(spec).ToList();
}
關(guān)于EF，我在2012年還寫過一篇關(guān)于性能的文章，至今也適用于.NET Core，歡迎參考：
《Performance tips for Entity Framework》
另外，在最新的EF Core 3.x中，微軟為了不被人罵EF性能差，直接默認(rèn)禁止了client side evaluation，避免了忘寫Include結(jié)果還開Lazy Load導(dǎo)致外鍵表被查詢幾百次的尷尬場面。
數(shù)據(jù)庫DTU
我的博客采用Azure SQL數(shù)據(jù)庫的DTU計(jì)量方式。請求頻繁的時(shí)候會(huì)導(dǎo)致DTU耗盡，從而后續(xù)請求需要排隊(duì)執(zhí)行。所以首先優(yōu)化的就是增加DTU容量，目前20個(gè)DTU基本管夠。
而DTU是否夠用可以直接在Azure的面板里看報(bào)表得到：
內(nèi)存及緩存，減少數(shù)據(jù)庫調(diào)用
計(jì)算機(jī)的內(nèi)存是為了用，而不是為了省。程序要么犧牲空間換時(shí)間，要么犧牲時(shí)間換空間。合理使用內(nèi)存做緩存，而不是每次都調(diào)用數(shù)據(jù)庫，可以提高一段時(shí)間內(nèi)的性能。特別是云端環(huán)境，數(shù)據(jù)庫的調(diào)用通常是最花時(shí)間的環(huán)節(jié)（Application Insights里認(rèn)為是dependency call）。即使不用內(nèi)存緩存，也可以根據(jù)項(xiàng)目需要配置redis等產(chǎn)品。
在我博客里，緩存的使用隨處可見。比如文章分類、Custom Page這種不經(jīng)常更新的數(shù)據(jù)，就可以緩存起來，這樣就不至于每次請求都去查詢數(shù)據(jù)庫。另外，像配置之類的數(shù)據(jù)，也建議設(shè)計(jì)成單例模式，網(wǎng)站啟動(dòng)時(shí)候加載完畢，不要每個(gè)請求都去數(shù)據(jù)庫里重新讀配置。這將極大的減少數(shù)據(jù)庫的壓力并提高網(wǎng)站響應(yīng)速度。
var cacheKey = $"page-{routeName.ToLower()}";
var pageResponse = await cache.GetOrCreateAsync(cacheKey, async entry =>
{
??? var response = await _customPageService.GetPageAsync(routeName);
??? return response;
});
除了數(shù)據(jù)庫，本地、遠(yuǎn)程圖片或其他類型的文件也可以利用緩存來提高性能。
CDN
盡量用CDN服務(wù)靜態(tài)資源，并配置pre-fetch，減少DNS解析次數(shù)。我的博客圖片由于設(shè)計(jì)了抽象隔離，博客的配圖并不是像訪問靜態(tài)資源那樣直接輸出到客戶端，目前支持兩種存儲(chǔ)方式：Azure Blob、本地文件系統(tǒng)，不管哪種存儲(chǔ)，都避免不了從對應(yīng)位置讀取圖片，并返回給客戶端顯示，即使加上了服務(wù)器端緩存（MemoryCache），這個(gè)過程也依然對服務(wù)器有較大壓力。
目前我選用的存儲(chǔ)方式為Azure Blob。以前讀取一張圖片的過程是：
首次請求：服務(wù)器去Azure Blob拿圖片，客戶端再去網(wǎng)站服務(wù)器拿圖片。
后續(xù)請求：Hit到memory cache，僅從網(wǎng)站服務(wù)器返回圖片給客戶端。
然而，即使后續(xù)請求不用經(jīng)過Azure Blob，對Web服務(wù)器的請求還是必須存在的，這也是挺大的開銷。于是，我通過CDN，讓圖片請求再也不經(jīng)過我自己的Web服務(wù)器，而是直接訪問Azure Blob。
于是現(xiàn)在，讀取一張圖片的過程是：
首次請求：CDN判斷自己是否已經(jīng)緩存了圖片，如果沒有，去Azure Blob里拿，并緩存起來。
首次請求：CDN判斷自己是否已經(jīng)緩存了圖片，如果沒有，去Azure Blob里拿，并緩存起來。
這樣一來，用戶閱讀博客文章時(shí)產(chǎn)生的圖片請求只會(huì)經(jīng)過Azure CDN的服務(wù)器，不會(huì)對Web服務(wù)器造成壓力。
另外，可以在網(wǎng)頁 header 上加個(gè) dns-prefetch，指向CDN服務(wù)器域名：
<link rel="dns-prefetch" href="https://cdn-blob.edi.wang" />
這樣瀏覽器就會(huì)提前解析CDN服務(wù)器的地址，進(jìn)一步加快網(wǎng)頁加載速度。
日志級別
很多程序員習(xí)慣本地和生產(chǎn)用同一份日志配置，而本地通常打開Debug、Trace等低等級日志以幫助我們的開發(fā)和測試工作，線上的產(chǎn)品是經(jīng)過測試的相對穩(wěn)定的發(fā)布版本，其實(shí)并不需要這些低等級日志，所有的事件都要記log的話會(huì)極大的影響應(yīng)用性能。所以我的實(shí)踐是生產(chǎn)環(huán)境只開Warning以上的日志級別，除非遇到刁鉆問題需要收集詳細(xì)爆炸數(shù)據(jù)，會(huì)臨時(shí)開幾個(gè)小時(shí)的Debug日志。
APM不要隨便加profiler
這條建議和上面類似，APM工具通常提供了各種profiler，然而這一般都會(huì)影響性能。就算是Azure自己的Application Insights也是如此。所以除非程序出現(xiàn)需要996調(diào)查的爆炸事故，一般不建議打開這些profiler。
總結(jié)
以上是我目前使用到的提升博客性能的方法。但是性能優(yōu)化沒有完全通用的策略，需要根據(jù)不同系統(tǒng)，不同業(yè)務(wù)，不同壓力來動(dòng)態(tài)調(diào)整優(yōu)化方案，總體思想即：減少不必要的調(diào)用與開銷。但有時(shí)候也需要調(diào)整應(yīng)用程序的部署架構(gòu)，比如Azure可以加上Traffic Manager、Front Door，使用負(fù)載均衡功能。歡迎大家留言分享自己的想法，以及對本文的補(bǔ)充和建議！
總結(jié)
以上是生活随笔為你收集整理的我的 .NET Core 博客性能优化经验总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： asp.net core 自定义基于 H
- 下一篇： csredis-in-asp.net c