我有一個使用ASP.NET與「InProc」會話處理的Web應用程序。通常情況下，一切運行正常，但每天幾百個請求比正常運行需要更長的時間。在IIS日誌中，我可以看到這些頁面（通常需要運行2-5秒）運行20秒以上。爲什麼頁面處理的AspNetSessionData階段會將我的頁面延遲20多秒？
我啓用了失敗請求的詳細模式跟蹤，並發現延遲在AspNetSessionData部分發生。在下面的示例中，AspNetSessionDataBegin和AspNetSessionDataEnd之間存在39秒的間隔。
我不確定接下來要做什麼。我找不到任何延遲的原因，我找不到任何可以啓用的日誌記錄功能來告訴我這裏發生了什麼。有誰知道爲什麼會發生這種情況，或者有任何建議可以幫我找到問題所需的額外步驟？
我的應用程序通常存儲在1-5MB會爲每個用戶，對搜索主要是緩存數據。該服務器有大量可用內存，並且只能運行大約50個用戶。
它可以通過爲會話狀態的鎖爭用而引起的。看看MSDN的最後一段ASP.NET Session State Overview。有關此主題，另請參閱K. Scott Allen's helpful post。
如果一個頁面都被註解的EnableSessionState =「真」（或繼承的web.config默認值），則該頁面所有請求都將獲得會話狀態的寫鎖。所有其他使用會話狀態的請求 - 即使它們沒有獲取寫入鎖定 - 都會被阻止，直到請求結束。
如果一個頁面用的EnableSessionState =「只讀」註明，則該頁面將無法獲得一個寫鎖，因此不會阻止其他請求。 （雖然它可能被另一個請求保持寫入鎖被阻止。）
爲了消除這種鎖爭用，你可能想實現自己的[細粒度]圍繞HttpContext.Cache對象或靜態WeakReference鎖國。後者可能更有效。 （理查德Kiessig見頁的Ultra-Fast ASP.NET 118-122。）
我還不確定Cache對象或WeakReferences對我們來說是不是很好的解決方案，但是對於問題的原因絕對是正確的。謝謝！ – 2011-05-05 16:36:58
一旦你想出適合你的解決方案，你可以評論嗎？我們還沒有但可能會遇到這種情況，我有興趣瞭解上面提到的替代方案。 – 2011-05-06 11:34:59
我們有一個解決方案，雖然我們還沒有完成它的實施。唯一真正關鍵的會話數據是我們需要的是用戶的ID。所以，我們只是將所有頁面（登錄頁面除外）更改爲「ReadOnly」模式。爲了完成這項工作，我們將把搜索緩存移動到一個自定義對象中，並將其他頁面改爲使用Context.Items而不是Session。 – 2011-06-07 13:59:08
有機會你都針對應用程序池被允許消耗的最大內存量，這會導致應用程序池重新啓動（這將佔到你看到在訪問延遲跑起來會議）。服務器上的內存量不會影響ASP.NET可以使用的內存量，這可以在memoryLimit屬性中的machine.config中進行控制，稍後在IIS自身中使用「最大內存已用」屬性進行控制。除此之外，您是否考慮過使用5 MB會話內存的每個用戶的替代方案？這不會很好地擴展，並且在負載下可能會導致很多問題。可能緩存是一個更有效的解決方案？如果搜索時間過長，您需要這樣做，SQL /數據庫設置是否可以進行優化以加快您的查詢速度？
我在Windows事件日誌中看不到任何應用程序池重新啓動消息，所以我不認爲這是問題的原因。此外，我們使用會話來跟蹤用戶的登錄，這意味着如果應用程序池重新啓動，則每個人都會註銷。我還沒有收到關於這種情況的任何報道。 – 2011-04-21 21:20:32
還有一點需要注意：這個應用沒有大量的用戶（每臺服務器50到200個），但每個用戶都使用大量數據。因此，我們有必要爲每個用戶緩存大量的數據。每個用戶5MB，即使200個用戶也只有1GB的RAM用於緩存。我們以這種方式設計了系統，並且在多年的環境中運行平穩。 – 2011-04-21 21:23:24
你知道任何有關緩慢請求？例如，他們是從數據庫中獲取數據嗎？他們是否在使用會話中的數據？ – 2011-04-26 13:56:49
調查的一個可能的途徑是鎖定會話狀態的爭用。看看最後一段http://msdn.microsoft.com/en-us/library/ms178581.aspx – 2011-04-26 13:57:30
參見http://odetocode.com/Blogs/scott/archive/2006/05/21/ session-state-uses-a-reader-writer-lock.aspx - 「當請求到達讀取和寫入會話變量的頁面時，運行時會獲取寫入者鎖定，寫入者鎖定會阻止同一會話中的其他頁面誰可能會寫入相同的會話變量。「 – 2011-04-26 13:58:54