生成的會話過多

Question

在我們的生產環境中（僅）會話數量過多似乎是從ASP.NET Web應用程序創建的。引人注目的症狀是ASPStateTempSessions表每小時產生約25,000條記錄（當谷歌分析顯示每小時該網站上少於500個獨特用戶時）。這導致了大量的等待任務，然後導致其他數據庫的速度下降和問題，從而阻礙了站點的性能。絕大多數會話似乎沒有任何大量的數據。

關於什麼可能會導致幻影會議的任何想法？我原本以爲圖像請求等會以某種方式導致新的會話，但這似乎不足以解釋如此高的乘數。這是否合理？我應該進一步探索這條街嗎？爲什麼我的開發環境中不會有相同的症狀？

謝謝！

環境細節（我可以提供更多的細節，我只是不知道還有什麼是相關的）：

• IIS 7
• SQL Server 2008中
• 會話模式是SQLServer的：
• • < sessionState mode =「SQLServer」sqlConnectionString =「[Connection String]」allowCustomSqlDatabase =「true」cookieless =「false」timeout =「120」cookieName =「XYZ_SessionId」/ >

Answer 1

我同意，可能的罪魁禍首是運行SessionStateModule平面文件，特別是如果你正在使用的不是web表單MVC。其原因是，爲了支持擴展名的URL路由，MVC添加以下代碼到你的web.config：

<modules runAllManagedModulesForAllRequests="true"> 
... 

屬性確實就像它的名字所暗示的，這將導致如果你主機架空體驗圖像在IIS中的同一網站。如果您不使用無擴展名網址，則可以考慮關閉該屬性，或者嘗試將圖像移動到CDN，如akamai或AWS cloudfront。

或者你可以尋找一個SessionStateModule替代方案，有一些可能會提供者交替行爲。你甚至可以通過繼承System.Web.SessionState.SessionStateStoreProviderBase來推出自己的產品，這裏有一個MSDN文章：custom session provider tutorial。如果你是最後一個，我最近發現ResetItemTimeout是默認SessionState模塊對每個請求的最常運行的項目。

最後，我認爲你正在經歷的擴展是由這種情況引起的原因是SessionState模塊默認是同步的。這意味着一個請求imageA.jpg和imageB.jpg的瀏覽器只有在imageA釋放會話鎖定之後纔會收到imageA和imageB。這比webserver的默認行爲慢得多，它將在單獨的線程上提供服務。

解決問題的另一種方法是，如果這不能解決問題，則查看通過IIS7發送的當前請求。爲此，請轉到IIS管理器左側的頂級服務器名稱，然後單擊「工作進程」。它應該列出你的網站進程，雙擊它，它會顯示所有當前的請求。你應該在那裏看到大量的圖像文件。