如果你在構建一個面向公衆的web站點，那麼在項目結尾時你想要實現的就是web負載性能良好。這意味着，你要確保你的產品在高負載下（50個併發 用戶或者每秒200個用戶等等）能夠運行，即使你認爲此時不會有那麼大的負載。久而久之，你的web站點可能吸引越來越多的用戶，此時如果web的負載難 以讓人忍受時，那麼自然而然網站開始走下坡路，意味着客戶流失以及名譽受損。
如果你在構建一個面向公衆的web站點，那麼在項目結尾時你想要實現的就是web負載性能良好。這意味着，你要確保你的產品在高負載下（50個併發 用戶或者每秒200個用戶等等）能夠運行，即使你認爲此時不會有那麼大的負載。久而久之，你的web站點可能吸引越來越多的用戶，此時如果web的負載難 以讓人忍受時，那麼自然而然網站開始走下坡路，意味着客戶流失以及名譽受損。
那麼可以採取哪些措施可以使得一個ASP.NET或者ASP.NET MVC應用更加高性能呢？
早期階段就要對應用進行負載測試
大多數開發者趨向在應用開發完成後，集成測試和迴歸測試通過後才進行負載測試。儘管在開發完成後執行一次負載測試好過不做，但是一旦完成了代碼的編 寫，修復性能問題就爲時已晚了。這個問題最常見的例子就是當應用程序在負載測試時不能正確響應時，就會考慮向外擴展（增加更多的服務器）。有時這是不可能 的，因爲代碼不適合實現擴展服務器。比如當對象是存儲在Session中並不可序列化時，這樣添加更多的web節點或者工作者進程就是不可能的。如果你在 開發的早期階段就發現你的應用可能要部署到多臺服務器上，那麼你應該在配置和服務器的數量等方面都要讓測試環境和最終環境儘可能地接近，這樣你的代碼會更 容易適應。
使用高性能類庫
近來我在診斷web站點的性能問題時發現了代碼中的一個熱點問題：來自第三方web服務的JSON信息必須要被反序列化多次。那些Json信息是由Newtonsoft.Json反序列化的，並且證明了Newtonsoft.Json在反序列化時不是最快的類庫，然後我們使用了一個更快的類庫（如ServiceStack）替代了Json.Net，並獲得了更好的結果。
如果我們在挑選了Json.Net作爲序列化類庫的早期階段就完成了負載測試，那麼我們就會更早地發現性能問題，我們就不必再代碼中做這麼多的修改了，也不必再次完整地重新測試了。
你的應用是CPU密集還是IO密集的？
在開始實現web應用以及設計項目時，你要首先考慮的一件事就是你的應用是CPU密集的還是IO密集的？這對於瞭解擴展應用的策略是很重要的。
比如，如果你的應用是CPU密集的，那麼你可能想使用同步模式，並行處理等等。然而，對於一個有很多IO受限的操作（例如和外部web服務或者網絡 資源如數據庫通訊）的產品，基於Task的異步模式可能對於向外擴展更有幫助。此外，爲了在未來的某天能夠創建Web Gardens和Web Farms,你可能想有一個集中式的緩存系統，這樣就實現了跨越多個工作者進程或服務的負載。
使用基於Task的異步模型，但要慎重
如果你的產品依賴許多IO受限的操作，或者包括了可能需要消耗寶貴的IIS線程等待一個操作完成的長時間運行的操作，你最好爲ASP.NET MVC項目考慮使用基於Task的異步模式。
互聯網上有很多關於異步的ASP.NET MVC actions的手冊（比如這個）， 所以這篇博客儘量避免介紹關於異步的知識點。然而，必須指出ASP.NET (MVC)中傳統的同步action會造成IIS線程繁忙直到操作完成或請求處理完成。這意味着如果如果web應用在等待一個外部的資源（如一個web服 務）響應，那麼該線程將是繁忙的。.Net線程池中可以用於處理請求的線程數量也是有限的，因此，儘可能快地釋放線程是很重要的。基於Task的異步 action或方法會在請求處理後釋放該線程，然後從線程池中獲取新的線程，並使用該新的線程返回該action的結果。這樣，多個請求可以由多個線程處 理，這會爲你的應用帶來更好的響應。
雖然TAP模式對於適當的應用來說很方便，但必須要慎重使用。當你使用TAP設計或者實現一個項目時，必須要注意幾個點（你可以點擊這裏查看）， 然而，開發者使用async和await關鍵字面臨的最大挑戰是知道在這個上下文中他們必須略有不同地處理線程。比如，可以創建一個返回Task（如 Task《Product》,博客園的markdown不支持單尖括號）的方法，通常你可以對那個Task調用Run()方法或者只調用 task.Result來迫使運行該task,直到拿到結果。
分發緩存和會話（session）狀態
開發者在單個開發機器上構建一個web應用是非常常見的，並且也會假設該產品運行在單個服務器上，然而對於面向大衆的web通常不是這樣的。它們往往被部署到一個叫做負載均衡之後的多個服務器上。儘管你仍然可以使用In-Proc（關於In-Proc和Out-Proc的知識點補充） 的模式和粘性（sticky）Session將一個web應用部署到多個服務器上（負載均衡器會將屬於相同session的所有請求定向到單個服務器）， 你可能必須保留session數據和緩存數據的多個副本。比如，如果你將產品部署到由4臺服務器組成的web farm上，並且你保持session數據爲In-Proc,那時一個請求到達一個已經包含緩存數據的機會是四分之一或25%，然而你如果在正確的地方使 用了集中式緩存機制，那麼爲每個請求找到緩存條目的機會就是100%。這對於嚴重依賴緩存數據的web應用是至關重要的。
使用集中式緩存機制（像App Fabric或Redis）的另一個好處是對實際的產品實現主動緩存系統的能力。主動緩存機制可以用於在客戶端請求一個條目之前就可以將最受歡迎的條目預 加載到緩存中。如果你使用實際的數據源來管理緩存同步時，那麼這會幫助你大幅地改善大數據驅動應用的性能。
創建Web Gardens
之前提到，在一個IO受限的web應用中包含了很多長時間運行的操作（如web服務的調用），此時你可能想儘可能地釋放主線程。默認情況下，每個 web應用運行在一個主線程下，該主線程爲保持web站點存活（alive）負責，但不幸的是，當它太忙的時候，你的站點就變得不能響應了。給應用添加更 多的“主線程”是一種辦法，這是通過將更多的工作者進程添加到IIS下的Web站點來實現的。每個工作者進程都會包括一個單獨的主線程，因此，如果一個主 線程繁忙，還有另外的主線程來處理到來的請求。
擁有多個工作者進程會將你的web站點變成一個Web Garden，這要求你將Session和應用數據持久化到Out-Proc中（例如一個state server或者Sql Server）。
巧妙地使用緩存和懶加載
無需強調，如果你將經常訪問的一點數據緩存到內存中，那麼這會減少數據庫和web服務的調用。正如之前所說，這對於IO受限的應用特別有幫助，當網站處於低負載時可能會造成不幸。
提高站點響應的另一種方式是使用懶加載。懶加載意味着應用裏不會有確定的數據片，但是它知道數據在哪裏。比如，如果web頁面上有一個下拉列表，這 意味着要顯示一個產品列表，一旦頁面加載完畢，不必從數據庫中加載所有的產品。你可以在頁面中添加一個jQuery函數，該函數可以在第一次下拉時填充下 拉列表。你也可以在代碼中的許多地方使用相同的技術，比如當使用Linq查詢和CLR集合時。
不要在MVC視圖中放C#代碼
ASP.NET MVC視圖會在運行時編譯而不是在編譯時，因此，如果在視圖中包含了太多的C#代碼，那麼你的代碼不會編譯後放到dll文件中。這樣做不僅有害於軟件的可 測試性，還會使web應用更慢，因爲每個頁面都有花更長的時間獲得顯示（因爲它們必須被編譯）。將代碼添加到視圖中的其他缺陷在於它們不能異步運行，這 樣，如果你決定基於TAP來構建應用時，就不能充分利用視圖中的異步方法和action了。
比如，如果你的代碼中有這麼一個方法：
public async Task<string> GetName(int code) { var result = … return await result; }該方法可以在一個異步的ASP.NET MVC action的上下文中異步運行，比如：
public Task<ActionResult> Index( CancellationToken ctx ) { var name = await GetName( 100 ); }但是如果在一個視圖中調用這方法，因爲該視圖不是異步的，所以必須以一種線程阻塞(thread-blocking)的方式運行，如：
var name = GetName(100).Result;
.Result會阻塞運行的線程，直到GetName()處理完成了請求，這樣該應用的執行會停止一會兒，然而當使用await關鍵字調用該代碼時，該線程不會被阻塞。
適當時使用Fire & Forget
注：Fire & Forget，字面意思是發射，然後忘記，不去理會了。網絡釋義爲射後不理。
如果兩個或多個操作沒有生成單個事務，那麼你很可能不必按順序運行它們。比如，如果一個用戶在你的站點註冊時創建了一個賬戶，一旦他們註冊了，你就把他們的詳細信息保存到數據庫，然後給他們發送一封郵件，你不必等待郵件發送出去才結束這個操作。
在這種情況下，最好的方法很可能就是開啓一個新的線程，讓它給用戶發送郵件，然後返回到主線程。這就叫做Fire& Forget，它可以提高應用的響應能力。
爲x64 CPU創建
32-bit的應用侷限於較低的內存量和可以訪問更少的CPU功能/指令。要克服這些限制，如果你的服務器是64-bit的，那麼要確保你的應用運 行在64-bit模式下（通過確保在IIS的32-bit模式下運行網站的選項是不是開啓）。然後爲x64 CPU編譯並生成代碼而不是Any CPU。
x64有用的一個例子是提高數據驅動應用的響應能力和性能，有一個好的緩存機制是必須的。In-proc是消耗內存的，因爲一切都存儲在網站的應用 程序池的內存邊界。對於x86進程來說，可以分配的內存量限制到4GB，這樣，如果加載到緩存中，這個限制很快就被打破。如果相同的站點是爲x64 CPU顯式生成的，那麼內存限制就不需考慮了，這樣更多的條目可以加到緩存中，然後和數據庫的通訊就少了，這會帶來更好的性能。
使用服務器上的監視和診斷工具
可能存在你肉眼看不到的更多的性能問題，因爲它們不會出現在錯誤日誌中。當應用程序已經部署到基本沒有機會調試的服務器上時，識別性能問題是更嚇人的事情。
要找出緩慢的處理，線程阻塞，懸掛，錯誤等等，強烈建議在服務器上安裝一個監視和診斷工具，讓它們持續地跟蹤和監視你的應用程序。我個人使用的是NewRelic檢查我的在線網站的健康。獲取詳細信息並創建免費賬號看這裏哦！
分析運行中的應用
一旦完成了網站開發，部署到IIS，然後附加一個分析器（如Visual Studio Profiler），然後抓取應用的多個部分的快照。比如抓取購買或者用戶註冊等操作的快照，然後檢查病查看是否存在任何造成緩慢或阻塞的代碼。在早期階 段找到那些熱點可能會節省你大量的時間，榮譽和金錢。
【編輯推薦】