StackExchange是構(gòu)建在ASP.NET和SQL Server基礎(chǔ)之上的項目。最近，Sam Saffron和Marc Gravell分別撰寫了博客，其中講述了他們發(fā)現(xiàn)和解決性能問題的經(jīng)驗，在該過程中最終追蹤到了.NET GC GEN-2對象。大家可以從他們的博文中吸取很多關(guān)于優(yōu)化生產(chǎn)環(huán)境中應(yīng)用程序性能的經(jīng)驗。

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

　　使用分析器。你可以使用類似于MVC-MiniProfiler的工具來分析方法調(diào)用，使用類似于.NET Memory Profiler或者Redgate ANTS Memory profiler之類的內(nèi)存分析器來跟蹤內(nèi)存使用情況。

　　如果可以的話，要擁有可查詢的日志——StackExchange團隊有后臺執(zhí)行的進程，它會解析原始的日志，并把它插入到大型的、專門的SQL Server實例中。如果無法查詢?nèi)罩荆敲茨憔蜔o法繪制出統(tǒng)計圖并查看趨勢或者模式。

　　理解GC是如何工作的——.NET中的垃圾回收器支持三代對象(GEN 0到GEN 2)，而存放時間最長的數(shù)據(jù)會使用GEN-2。GEN-2的掃描頻率最低，執(zhí)行的成本最高，甚至可能會堵塞其它線程。Sam建議閱讀Rico的《Garbage Collector Basics and Performance Hints》一文以獲得更多細節(jié)。

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

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

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

　　你在擴展ASP.NET應(yīng)用程序的時候，也有發(fā)現(xiàn)和解決瓶頸問題的類似經(jīng)驗和大家分享嗎?