ASP.NET的Session State
為此ASP 的使用者不得不自己手工將會話信息以會話 ID 為主鍵同步到外部數據庫中，以緩解類似問題。
而在 ASP.NET 中，因為設計時就考慮了這些問題，能夠避免這些限制：1.支持進程外的狀態管理，通過獨立狀態管理服務或 SQL Server 狀態服務器管理會話狀態2.支持不使用 Cookie 的狀態維護，通過在 URL 中自動增加會話 ID 來避免使用 Cookie 3.通過獨立的狀態管理服務或SQL Server 狀態服務器支持負載均衡時同步使用會話信息實現這些特性的正是上節提到的Session StateModule.InitModuleFromConfig 函數中，根據Session State 標記的 mode 屬性選擇的四種不同的狀態管理器實現。
以下內容為程序代碼：
- <system.web>
- <sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1：42424"
stateNetworkTimeout="10" sqlConnectionString="data source=127.0.0.1；- Integrated Security=SSPI" cookieless="false" timeout="20" />
- </system.web>
Off模式禁止會話管理，同時 ASP.NET 還允許通過在頁面中以 Enable Session State 屬性細粒度管理頁面的會話支持狀態以下內容為程序代碼：
- <%@ Page EnableSessionState=" True|False|ReadOnly" %>
InProc 模式兼容以前 ASP 的策略，在 ASP.NET 同一進程空間內實現基于內存的會話狀態管理，速度最快但受到與 ASP 相同的限制；STATE SERVER 模式通過 ASP.NET 獨立安裝的 ASP.NET State Service 服務（aspnet_state.exe），以 stateConnectionString 指定的IP和端口響應會話狀態服務；SQLServer 模式則通過 sqlConnectionString 指定的 SQL Server 服務器，以內存臨時表（以 InstallSqlState.sql建庫，使用 tempdb 內存數據庫）或獨立表（以InstallPersistSqlState.sql 監控，使用獨立的 ASPState 庫）維護會話狀態。
這四種不同的狀態管理器，在性能上據《Performance Tuning and Optimizing ASP.NET Appliation》一書的測試，相對值如下：以下為引用：Table 4-1： Normalized TTLB（Time to Last Byte） bySession State Mode （in Milliseconds per 100 Requests）
CONCURRENT BROWSERS MODE = OFF MODE = INPROC MODE = STATE SERVER MODE = SQLSERVER 1 7.81 4.54 8.27 8.47 5 28.28 20.25 27.25 29.29 10 89.38 46.08 77.29 85.11 Table 4-2： Average Requests per Second bySession State Mode CONCURRENT BROWSERS MODE = OFF MODE = INPROC MODE = STATE SERVER MODE = SQLSERVER 1 18.86 24.17 18.31 18.11 5 21.66 25.74 21.54 21.34 10 17.23 23.8 18.11 17.6可以看到，無論是從 TTLB 還是每秒平均請求數來說，進程外狀態管理器的性能都是可以令人接受的，當然還需要針對狀態管理情況在編寫代碼時做相關優化。不過要使用進程外狀態管理器，則保存在會話中的對象受到必須提高二進制序列化支持的限制。
從使用角度來看，狀態管理器實際上都是由上節提到的 HttpSessionModule 建立管理，并通過 Http Session State 接口提供訪問的，結構如下圖：MSDN 上的 Underpinnings of theSession State Implementation in ASP.NET 一文非常詳細的解釋了幾種不同狀態管理器的原理和使用，這兒就不羅嗦了。
【編輯推薦】
