如果你在構(gòu)建一個(gè)面向公眾的web站點(diǎn)，那么在項(xiàng)目結(jié)尾時(shí)你想要實(shí)現(xiàn)的就是web負(fù)載性能良好。這意味著，你要確保你的產(chǎn)品在高負(fù)載下（50個(gè)并發(fā) 用戶或者每秒200個(gè)用戶等等）能夠運(yùn)行，即使你認(rèn)為此時(shí)不會(huì)有那么大的負(fù)載。久而久之，你的web站點(diǎn)可能吸引越來越多的用戶，此時(shí)如果web的負(fù)載難 以讓人忍受時(shí)，那么自然而然網(wǎng)站開始走下坡路，意味著客戶流失以及名譽(yù)受損。

那么可以采取哪些措施可以使得一個(gè)ASP.NET或者ASP.NET MVC應(yīng)用更加高性能呢？

早期階段就要對(duì)應(yīng)用進(jìn)行負(fù)載測(cè)試

大多數(shù)開發(fā)者趨向在應(yīng)用開發(fā)完成后，集成測(cè)試和回歸測(cè)試通過后才進(jìn)行負(fù)載測(cè)試。盡管在開發(fā)完成后執(zhí)行一次負(fù)載測(cè)試好過不做，但是一旦完成了代碼的編 寫，修復(fù)性能問題就為時(shí)已晚了。這個(gè)問題最常見的例子就是當(dāng)應(yīng)用程序在負(fù)載測(cè)試時(shí)不能正確響應(yīng)時(shí)，就會(huì)考慮向外擴(kuò)展（增加更多的服務(wù)器）。有時(shí)這是不可能 的，因?yàn)榇a不適合實(shí)現(xiàn)擴(kuò)展服務(wù)器。比如當(dāng)對(duì)象是存儲(chǔ)在Session中并不可序列化時(shí)，這樣添加更多的web節(jié)點(diǎn)或者工作者進(jìn)程就是不可能的。如果你在 開發(fā)的早期階段就發(fā)現(xiàn)你的應(yīng)用可能要部署到多臺(tái)服務(wù)器上，那么你應(yīng)該在配置和服務(wù)器的數(shù)量等方面都要讓測(cè)試環(huán)境和最終環(huán)境盡可能地接近，這樣你的代碼會(huì)更 容易適應(yīng)。

使用高性能類庫

近來我在診斷web站點(diǎn)的性能問題時(shí)發(fā)現(xiàn)了代碼中的一個(gè)熱點(diǎn)問題：來自第三方web服務(wù)的JSON信息必須要被反序列化多次。那些Json信息是由Newtonsoft.Json反序列化的，并且證明了Newtonsoft.Json在反序列化時(shí)不是最快的類庫，然后我們使用了一個(gè)更快的類庫（如ServiceStack）替代了Json.Net，并獲得了更好的結(jié)果。

如果我們?cè)谔暨x了Json.Net作為序列化類庫的早期階段就完成了負(fù)載測(cè)試，那么我們就會(huì)更早地發(fā)現(xiàn)性能問題，我們就不必再代碼中做這么多的修改了，也不必再次完整地重新測(cè)試了。

你的應(yīng)用是CPU密集還是IO密集的？

在開始實(shí)現(xiàn)web應(yīng)用以及設(shè)計(jì)項(xiàng)目時(shí)，你要首先考慮的一件事就是你的應(yīng)用是CPU密集的還是IO密集的？這對(duì)于了解擴(kuò)展應(yīng)用的策略是很重要的。

比如，如果你的應(yīng)用是CPU密集的，那么你可能想使用同步模式，并行處理等等。然而，對(duì)于一個(gè)有很多IO受限的操作（例如和外部web服務(wù)或者網(wǎng)絡(luò) 資源如數(shù)據(jù)庫通訊）的產(chǎn)品，基于Task的異步模式可能對(duì)于向外擴(kuò)展更有幫助。此外，為了在未來的某天能夠創(chuàng)建Web Gardens和Web Farms,你可能想有一個(gè)集中式的緩存系統(tǒng)，這樣就實(shí)現(xiàn)了跨越多個(gè)工作者進(jìn)程或服務(wù)的負(fù)載。

使用基于Task的異步模型，但要慎重

如果你的產(chǎn)品依賴許多IO受限的操作，或者包括了可能需要消耗寶貴的IIS線程等待一個(gè)操作完成的長時(shí)間運(yùn)行的操作，你最好為ASP.NET MVC項(xiàng)目考慮使用基于Task的異步模式。

互聯(lián)網(wǎng)上有很多關(guān)于異步的ASP.NET MVC actions的手冊(cè)（比如這個(gè)）， 所以這篇博客盡量避免介紹關(guān)于異步的知識(shí)點(diǎn)。然而，必須指出ASP.NET (MVC)中傳統(tǒng)的同步action會(huì)造成IIS線程繁忙直到操作完成或請(qǐng)求處理完成。這意味著如果如果web應(yīng)用在等待一個(gè)外部的資源（如一個(gè)web服 務(wù)）響應(yīng)，那么該線程將是繁忙的。.Net線程池中可以用于處理請(qǐng)求的線程數(shù)量也是有限的，因此，盡可能快地釋放線程是很重要的。基于Task的異步 action或方法會(huì)在請(qǐng)求處理后釋放該線程，然后從線程池中獲取新的線程，并使用該新的線程返回該action的結(jié)果。這樣，多個(gè)請(qǐng)求可以由多個(gè)線程處 理，這會(huì)為你的應(yīng)用帶來更好的響應(yīng)。

雖然TAP模式對(duì)于適當(dāng)?shù)膽?yīng)用來說很方便，但必須要慎重使用。當(dāng)你使用TAP設(shè)計(jì)或者實(shí)現(xiàn)一個(gè)項(xiàng)目時(shí)，必須要注意幾個(gè)點(diǎn)（你可以點(diǎn)擊這里查看）， 然而，開發(fā)者使用async和await關(guān)鍵字面臨的最大挑戰(zhàn)是知道在這個(gè)上下文中他們必須略有不同地處理線程。比如，可以創(chuàng)建一個(gè)返回Task（如 Task《Product》,博客園的markdown不支持單尖括號(hào)）的方法，通常你可以對(duì)那個(gè)Task調(diào)用Run()方法或者只調(diào)用 task.Result來迫使運(yùn)行該task,直到拿到結(jié)果。

分發(fā)緩存和會(huì)話（session）狀態(tài)

開發(fā)者在單個(gè)開發(fā)機(jī)器上構(gòu)建一個(gè)web應(yīng)用是非常常見的，并且也會(huì)假設(shè)該產(chǎn)品運(yùn)行在單個(gè)服務(wù)器上，然而對(duì)于面向大眾的web通常不是這樣的。它們往往被部署到一個(gè)叫做負(fù)載均衡之后的多個(gè)服務(wù)器上。盡管你仍然可以使用In-Proc（關(guān)于In-Proc和Out-Proc的知識(shí)點(diǎn)補(bǔ)充） 的模式和粘性（sticky）Session將一個(gè)web應(yīng)用部署到多個(gè)服務(wù)器上（負(fù)載均衡器會(huì)將屬于相同session的所有請(qǐng)求定向到單個(gè)服務(wù)器）， 你可能必須保留session數(shù)據(jù)和緩存數(shù)據(jù)的多個(gè)副本。比如，如果你將產(chǎn)品部署到由4臺(tái)服務(wù)器組成的web farm上，并且你保持session數(shù)據(jù)為In-Proc,那時(shí)一個(gè)請(qǐng)求到達(dá)一個(gè)已經(jīng)包含緩存數(shù)據(jù)的機(jī)會(huì)是四分之一或25%，然而你如果在正確的地方使 用了集中式緩存機(jī)制，那么為每個(gè)請(qǐng)求找到緩存條目的機(jī)會(huì)就是100%。這對(duì)于嚴(yán)重依賴緩存數(shù)據(jù)的web應(yīng)用是至關(guān)重要的。

使用集中式緩存機(jī)制（像App Fabric或Redis）的另一個(gè)好處是對(duì)實(shí)際的產(chǎn)品實(shí)現(xiàn)主動(dòng)緩存系統(tǒng)的能力。主動(dòng)緩存機(jī)制可以用于在客戶端請(qǐng)求一個(gè)條目之前就可以將最受歡迎的條目預(yù) 加載到緩存中。如果你使用實(shí)際的數(shù)據(jù)源來管理緩存同步時(shí)，那么這會(huì)幫助你大幅地改善大數(shù)據(jù)驅(qū)動(dòng)應(yīng)用的性能。

創(chuàng)建Web Gardens

之前提到，在一個(gè)IO受限的web應(yīng)用中包含了很多長時(shí)間運(yùn)行的操作（如web服務(wù)的調(diào)用），此時(shí)你可能想盡可能地釋放主線程。默認(rèn)情況下，每個(gè) web應(yīng)用運(yùn)行在一個(gè)主線程下，該主線程為保持web站點(diǎn)存活（alive）負(fù)責(zé)，但不幸的是，當(dāng)它太忙的時(shí)候，你的站點(diǎn)就變得不能響應(yīng)了。給應(yīng)用添加更 多的“主線程”是一種辦法，這是通過將更多的工作者進(jìn)程添加到IIS下的Web站點(diǎn)來實(shí)現(xiàn)的。每個(gè)工作者進(jìn)程都會(huì)包括一個(gè)單獨(dú)的主線程，因此，如果一個(gè)主 線程繁忙，還有另外的主線程來處理到來的請(qǐng)求。

擁有多個(gè)工作者進(jìn)程會(huì)將你的web站點(diǎn)變成一個(gè)Web Garden，這要求你將Session和應(yīng)用數(shù)據(jù)持久化到Out-Proc中（例如一個(gè)state server或者Sql Server）。

巧妙地使用緩存和懶加載

無需強(qiáng)調(diào)，如果你將經(jīng)常訪問的一點(diǎn)數(shù)據(jù)緩存到內(nèi)存中，那么這會(huì)減少數(shù)據(jù)庫和web服務(wù)的調(diào)用。正如之前所說，這對(duì)于IO受限的應(yīng)用特別有幫助，當(dāng)網(wǎng)站處于低負(fù)載時(shí)可能會(huì)造成不幸。

提高站點(diǎn)響應(yīng)的另一種方式是使用懶加載。懶加載意味著應(yīng)用里不會(huì)有確定的數(shù)據(jù)片，但是它知道數(shù)據(jù)在哪里。比如，如果web頁面上有一個(gè)下拉列表，這 意味著要顯示一個(gè)產(chǎn)品列表，一旦頁面加載完畢，不必從數(shù)據(jù)庫中加載所有的產(chǎn)品。你可以在頁面中添加一個(gè)jQuery函數(shù)，該函數(shù)可以在第一次下拉時(shí)填充下 拉列表。你也可以在代碼中的許多地方使用相同的技術(shù)，比如當(dāng)使用Linq查詢和CLR集合時(shí)。

不要在MVC視圖中放C#代碼

ASP.NET MVC視圖會(huì)在運(yùn)行時(shí)編譯而不是在編譯時(shí)，因此，如果在視圖中包含了太多的C#代碼，那么你的代碼不會(huì)編譯后放到dll文件中。這樣做不僅有害于軟件的可 測(cè)試性，還會(huì)使web應(yīng)用更慢，因?yàn)槊總€(gè)頁面都有花更長的時(shí)間獲得顯示（因?yàn)樗鼈儽仨毐痪幾g）。將代碼添加到視圖中的其他缺陷在于它們不能異步運(yùn)行，這 樣，如果你決定基于TAP來構(gòu)建應(yīng)用時(shí)，就不能充分利用視圖中的異步方法和action了。

比如，如果你的代碼中有這么一個(gè)方法：

public async Task<string> GetName(int code) 
{ 
 
    var result = … 
 
    return await result; 
 
} 

該方法可以在一個(gè)異步的ASP.NET MVC action的上下文中異步運(yùn)行，比如：

public Task<ActionResult> Index( CancellationToken ctx ) 
{ 
    var name = await GetName( 100 ); 
} 

但是如果在一個(gè)視圖中調(diào)用這方法，因?yàn)樵撘晥D不是異步的，所以必須以一種線程阻塞(thread-blocking)的方式運(yùn)行，如：

var name = GetName(100).Result; 

.Result會(huì)阻塞運(yùn)行的線程，直到GetName()處理完成了請(qǐng)求，這樣該應(yīng)用的執(zhí)行會(huì)停止一會(huì)兒，然而當(dāng)使用await關(guān)鍵字調(diào)用該代碼時(shí)，該線程不會(huì)被阻塞。

適當(dāng)時(shí)使用Fire & Forget

注：Fire & Forget，字面意思是發(fā)射，然后忘記，不去理會(huì)了。網(wǎng)絡(luò)釋義為射后不理。
如果兩個(gè)或多個(gè)操作沒有生成單個(gè)事務(wù)，那么你很可能不必按順序運(yùn)行它們。比如，如果一個(gè)用戶在你的站點(diǎn)注冊(cè)時(shí)創(chuàng)建了一個(gè)賬戶，一旦他們注冊(cè)了，你就把他們的詳細(xì)信息保存到數(shù)據(jù)庫，然后給他們發(fā)送一封郵件，你不必等待郵件發(fā)送出去才結(jié)束這個(gè)操作。

在這種情況下，最好的方法很可能就是開啟一個(gè)新的線程，讓它給用戶發(fā)送郵件，然后返回到主線程。這就叫做Fire& Forget，它可以提高應(yīng)用的響應(yīng)能力。

為x64 CPU創(chuàng)建

32-bit的應(yīng)用局限于較低的內(nèi)存量和可以訪問更少的CPU功能/指令。要克服這些限制，如果你的服務(wù)器是64-bit的，那么要確保你的應(yīng)用運(yùn) 行在64-bit模式下（通過確保在IIS的32-bit模式下運(yùn)行網(wǎng)站的選項(xiàng)是不是開啟）。然后為x64 CPU編譯并生成代碼而不是Any CPU。

x64有用的一個(gè)例子是提高數(shù)據(jù)驅(qū)動(dòng)應(yīng)用的響應(yīng)能力和性能，有一個(gè)好的緩存機(jī)制是必須的。In-proc是消耗內(nèi)存的，因?yàn)橐磺卸即鎯?chǔ)在網(wǎng)站的應(yīng)用 程序池的內(nèi)存邊界。對(duì)于x86進(jìn)程來說，可以分配的內(nèi)存量限制到4GB，這樣，如果加載到緩存中，這個(gè)限制很快就被打破。如果相同的站點(diǎn)是為x64 CPU顯式生成的，那么內(nèi)存限制就不需考慮了，這樣更多的條目可以加到緩存中，然后和數(shù)據(jù)庫的通訊就少了，這會(huì)帶來更好的性能。

使用服務(wù)器上的監(jiān)視和診斷工具

可能存在你肉眼看不到的更多的性能問題，因?yàn)樗鼈儾粫?huì)出現(xiàn)在錯(cuò)誤日志中。當(dāng)應(yīng)用程序已經(jīng)部署到基本沒有機(jī)會(huì)調(diào)試的服務(wù)器上時(shí)，識(shí)別性能問題是更嚇人的事情。

要找出緩慢的處理，線程阻塞，懸掛，錯(cuò)誤等等，強(qiáng)烈建議在服務(wù)器上安裝一個(gè)監(jiān)視和診斷工具，讓它們持續(xù)地跟蹤和監(jiān)視你的應(yīng)用程序。我個(gè)人使用的是NewRelic檢查我的在線網(wǎng)站的健康。獲取詳細(xì)信息并創(chuàng)建免費(fèi)賬號(hào)看這里哦！

分析運(yùn)行中的應(yīng)用

一旦完成了網(wǎng)站開發(fā)，部署到IIS，然后附加一個(gè)分析器（如Visual Studio Profiler），然后抓取應(yīng)用的多個(gè)部分的快照。比如抓取購買或者用戶注冊(cè)等操作的快照，然后檢查病查看是否存在任何造成緩慢或阻塞的代碼。在早期階 段找到那些熱點(diǎn)可能會(huì)節(jié)省你大量的時(shí)間，榮譽(yù)和金錢。