ASP.NET Session會導致的性能問題

2024-07-10 12:38:41

字體：大中小

來源：轉載

供稿：網友

而且還是陣發性的，有某個用戶投訴慢的時候，你訪問卻很快，本地又復現不出來？今天你訪問了博客園真是太幸運了，也許這里就有你想要的一個答案——假如你的站點動態處理了圖片或者其他原本不會動態處理的非網頁資源的話。沒想到吧，這是Session惹的禍！
我們公司某個站點訪問量一直很大，幾年前就已經發現客戶經常投訴說很慢，而這個問題我們一直都在排查和解決。從線路問題，到數據庫連接泄露，到數據庫死鎖、索引，以及程序的優化問題，我們都查找過，并且解決過。然而，這個問題總還是存在。比如說，在IIS日志中，就會經常看到time-taken大于10秒鐘的訪問。而最近我們的KPI要求解決這個問題，不得已，再次踏上這趟艱難的排查之旅。

       之所以說艱難，是因為這個現象在本地幾乎無法復現，一個是這個現象是陣發性的，第二個是本地訪問量或者數據量不夠大。我們也嘗試過在本地加載線上服務器的數據庫，然后拿服務器的IIS的Log文件重播，結果確實是偶爾發現IIS日志中的time-taken也會比較長，但是本地服務器性能不如線上服務器的，比如說IO就差很遠，于是總說不清楚到底是什么問題。而線上服務器也不方便用做Dump的形式查找：第一是因為線上一做Dump，站點就會在幾分鐘內失去響應，這樣我們客服的電話就會被打爆；另一個原因還是陣發性的問題，我們不可能一直盯著性能看，然后在發生問題的瞬間做Dump。再說了，看性能也看不出來，因為那些響應時間很長的訪問，其前后附近的響應都特別的快。不可避免的，我們只能夠在代碼里面塞入一些調試和日志的代碼，以期望能夠得到一些有用的信息。

       最開始的時候，我們認為最可能的原因是數據庫阻塞，比如正好某一個訪問鎖住某個數據庫對象（比如一張表或者某幾行），如果這個時候訪問特定的頁面，可能就會比較慢。于是在數據庫層塞入了一堆代碼，這些代碼會在數據庫連接數量多，或者某個數據庫連接時間特別長的時候，將所有數據庫連接的當前訪問語句、連接持續總時間，以及這些連接當前的堆棧情況都輸出到文件中。與此同時，我們還打開Sql profiler對這個數據庫進行監視，將持續時間超過1秒鐘的都記錄下來。然而跑了一天之后，卻發現什么都沒有被記錄下來，但IIS日志中仍然在這段時間內出現許多10秒以上的訪問。這個時候，我們就意識到，可能方向錯了。

       接著，我們就開始塞另外一段代碼：一個IHttpModule。這個模塊就只是截獲每一個頁面訪問的完整生命周期中的所有事件，比如BeginRequest、PreAuthenticateRequest等。同時在BeginRequest開始的時候設置一個定時器，每隔一秒鐘就會出發一個事件，來記錄本次訪問過程中，本模塊收集到的所有線程中當前的堆棧情況。最后，在EndRequest的時候，如果訪問時間超過5秒，就將之前截獲的所有信息輸出到文件中。這一下子問題就變得非常的清晰了，比如說，下面這種輸出（片斷）就是非常典型的一個情況：

上一篇：ASP.NET 頁面中動態增加的控件、添加事件第1/2頁

下一篇：asp.net 存儲過程調用