ASP.NET企業級應用性能優化-內存分析

爲什麼要寫篇文章

 

談到 ASP.NET 應用的開發，使我不禁想起之前有朋友對我說過的一句話：做網站沒有任何的技術含量。後來他告訴我，做網站，在 .NET 平臺上面很簡單，不就是拖幾個控件，搞點佈局，寫點 js ，然後敲上幾個數據的增刪查改就完了，系統大了，就多敲幾個。當時，朋友之所以說這樣的話，是與他的公司與項目背景相關的。

 

在很多的外包公司裏面，常常用 ASP.NET 來快速的搭建一個 Web 應用，例如 OA 系統，企業門戶，管理系統，而這些系統往往都注重在業務流程上面，不會在其他方面關注過多，例如，性能，使用這些系統的用戶也不多，頂多幾千個，所以對於很多真正觸及到 Web 應用的要考慮的問題，例如，高併發，高性能，穩定，安全等，沒有接觸到。後來，我去了其他的公司，接觸到那種承受百萬，千萬級訪問量的應用的時候，越發覺得自己有很多的知識需要學習。

 

在與朋友共事的一些項目中，很多項目的性能都很差，我們大家都想解決這個問題，但是都沒有辦法，僅僅只是知道一些基本的措施，很多都是從網絡上面「道聽途說」，例如用 stringbuilder 來拼接字符串，儘量用 for 而不是 foreach 。其實說到底，還是我們對 .NET 不夠深入，雖然說，我們在 .NET 平臺上面做了很多的項目，其實很多的應用只是在 .NET 平臺的表層開發。（由此可見，「題海戰術」不一定能夠練就解題高手，也不一定能夠練就解決問題的思維。）

 

其實性能優化問題，不僅僅只是 Web 應用獨有的，而是說，在 Web 應用中，可能關注的多一點。本篇文章談的是 ASP.NET 應用的性能優化，其實，從本質上面，還是談的 .NET 應用的優化。對於其他平臺的朋友，也是非常有參考價值的。

 

          在本篇文章中，不會談及很多的調優的方法理論（其實這些方法論是很有作用的），我會從談及一些實際，可操作性的知識，讓朋友們學而即用，同時也讓朋友對開始對 .NET 加深認識。

 

          本篇的內容從以下幾個方面進行展開： 內存瓶頸分析， CPU 瓶頸分析，緩存分析，資源等待分析，數據庫瓶頸分析， HTTP 優化 。

 

首先來看看內存瓶頸分析。雖然，我在之前的一篇稿子《 .NET 企業級開發》中談   這個問題，但是，爲了本篇文章的完整性，我還是提一下，同時也將這個問題講更全面一些。

 

 

內存瓶頸分析

 

內存性能問題可以分爲兩個部分：內部內存壓力，外部內存壓力。其中內部內存壓力主要是站點本身在運行的過程中消耗過多的內存，基本是可以從託管資源，非託管資源兩方面分析；而外部內存壓力指代站點所在的服務器上面的其他應用於站點本身之間進行資源的爭奪，從而使得站點可以使用的內存太少。那麼在 ASP.NET 企業級應用中，我們技術人員關注點可以放在內部內存壓力。

 

首先看看託管資源的問題。

 

爲什麼要討論託管資源？因爲託管資源（就是分配中在託管堆上面的對象），分配在託管堆上，而託管堆在內存中，所有託管資源的合理的分配和回收，會對內存產生影響。

 

       ASP.NET 應用的功能就是由很多的對象組合完成的，所以討論託管資源很有必要。

        在 .NET 中，託管堆分爲兩類：大對象託管堆，小對象託管堆。一般而言，如果對象所佔的空間小於 85K ，就分配在小堆上面，反之，分配在大堆上面。如圖的小堆圖：

 

 

    在對上面，對象被劃分爲三代： 0,1,2 代。「代」數越大，被回收的可能性就越小。基於這個理論，就要避免原本只要是低代的對象變爲高代的對象，例如某個對象用完之後就銷燬的，原本是 0 代的，現在存活到了 2 代，那麼它所佔的內存就浪費了。雖然，垃圾回收機制沒有在一定程度上回收，但是如果我們總是「霸佔」着對象，垃圾回收也沒有辦法。

 

        下面，舉個例子，形象的說明一下。對於一個大型的 ASP.NET 應用而言，裏面會包含很多的對象，假設 10000 個，其中每次請求都要產生的 100 個臨時對象。如果這些臨時對象，被不合理的分配，成爲了大代的對象，我們來算一算。

 

如果這個 100 個對象每個佔 1k 的空間，那麼 100 個，我們約等於 0.1M ，如果站點訪問量是 10w ，那麼如果這些 0.1 乘以 10w ，如果訪問量是 100w ， 1000w ，結果如何？大家已經清楚了。很多，需要將問題放大來看，結果就很清晰了。

 

        對於對象的使用，有一點要記住：儘可能遲的分配，儘可能早的釋放。

        下面，我們可以談談，如何找出內存問題。

 

        可以採用工具加分析的方式。可以採用 System Counter ， CLR Profiler ， ANTS Memory Profiler(Red Gate) 等。其中 System Counter ， CLR Profiler 分析的比較的粗糙， ANTS Memory Profiler(Red Gate) 可以指出是哪段代碼有問題，方便解決問題。如圖

 

 

   本篇由於篇幅的限制，先到這裏，下一篇，我們可以看看一些常見的性能問題，例如字符串相關問題，Session，緩存，對象池。

 

本文轉自yanyangtian51CTO博客，原文鏈接：http://blog.51cto.com/yanyangtian/755160  ，如需轉載請自行聯繫原作者