StackExchange是構建在ASP.NET和SQL Server基礎之上的項目。最近，Sam Saffron和Marc Gravell分別撰寫了博客，其中講述了他們發現和解決性能問題的經驗，在該過程中最終追蹤到了.NET GC GEN-2對象。大家可以從他們的博文中吸取很多關于優化生產環境中應用程序性能的經驗。

　　問題是由自定義標簽引擎引起的，它會在內存中存放大型對象列表。這兩篇博文都值得一讀，而Sam的文章則更詳細地講述了如何診斷問題。其中主要的應對方法包括：

• 使用分析器。你可以使用類似于MVC-MiniProfiler的工具來分析方法調用，使用類似于.NET Memory Profiler或者Redgate ANTS Memory profiler之類的內存分析器來跟蹤內存使用情況。
• 如果可以的話，要擁有可查詢的日志——StackExchange團隊有后臺執行的進程，它會解析原始的日志，并把它插入到大型的、專門的SQL Server實例中。如果無法查詢日志，那么你就無法繪制出統計圖并查看趨勢或者模式。
• 理解GC是如何工作的——.NET中的垃圾回收器支持三代對象（GEN 0到GEN 2），而存放時間最長的數據會使用GEN-2。GEN-2的掃描頻率最低，執行的成本最高，甚至可能會堵塞其它線程。Sam建議閱讀Rico的《Garbage Collector Basics and Performance Hints》一文以獲得更多細節。

　　最后，團隊采取了多項優化措施，包括針對應用程序的特定部分，從對象數組切換到索引數組，從類切換到結構體等。第一項措施是一種很常用的模式，這樣數組就只針對主要的不可變列表的索引；而第二項并不常用，Sam建議只在有超過50萬個對象以上才使用它，這樣在達到第二代垃圾回收器標準的時候就會很快釋放內存。

　　StackExchange團隊對性能問題非常關注--比方說，你可以看到StackOverflow在三個不同的等級上使用caching，從而提升反應時間，減少服務器的負載。

　　在InfoQ上和MSDN上都有很多關于性能和可伸縮性的資源可供參考，包括這篇Rob Howard撰寫的文章。最后，引用Sam的話：“做很少的工作總是要比做更多工作消耗的資源少。”

　　你在擴展ASP.NET應用程序的時候，也有發現和解決瓶頸問題的類似經驗和大家分享嗎？

　　查看英文原文：How Do You Tune Your Application For Performance?