Asp.net項目因Session阻塞致使頁面打開速度變慢

現象：在一個網站中，當訪問一個處理比較耗時的頁面（A頁面），頁面請求尚未返回時，此時再點擊訪問該網站的其餘頁面（B頁面）會出現B頁面好久都沒有響應和返回，直到A頁面輸出返回數據時纔開始處理B頁面的請求，形成請求排隊處理，A頁面阻塞了B頁面的請求處理。

　　開始我一直懷疑是否是瀏覽器單線程的緣故，在網上搜索了資料，IE6/7，FF都是多線程瀏覽器（IE6好像是2個線程），用IE六、IE七、FF都試過了，結果同樣，這就奇怪了，明明都是多線程，怎麼會阻塞呢？

　　在網上搜索了好幾回相關的問題，仍是沒查出個因此然，但網站形成的客戶體驗確實不好，每當訪問到那個耗時的A頁面時，再想訪問其餘頁面根本查看不了。「怎麼系統那麼慢」，暈，沒辦法，我也不懂怎麼處理（不負責任的態度啊，呵呵）。

　　在一次的無心中我發現居然在A頁面Loading（頁面上加的提示）的時候，能夠訪問某個頁面，真是驚喜，再試試幾回，能夠，確實能夠，是否是頁面代碼阻塞了？因而查這兩個頁面的代碼，其實這兩個頁面的代碼就十幾行，沒什麼問題呢。

　　通過屢次嘗試和比對，才發現這兩個頁都是無需登錄驗證的頁面，以前出現阻塞的頁面都是需登錄驗證後纔可訪問的頁面，而系統的驗證信息是存儲在Session中，經過Session判斷驗證的。這時想到應該是Session的問題，但仍是不知如何處理，再去網上搜索，互聯網上的信息真是應有盡有，終於搜索到問題所在：

　　/************************************************************/

　　問：爲了能夠順序訪問Session的狀態值，Session是否提供了鎖定機制？

　　答：Session實現了Reader/Writer的鎖機制：

　　當頁面對Session具備可寫功能（即頁面有<%@ Page EnableSessionState="True" %>標記），此時直到請求完成該頁面的Session持有一個寫鎖定。

　　當頁面對Session具備只讀功能（即頁面有<%@ Page EnableSessionState="ReadOnly" %>標記），此時知道請求完成該頁面的Session持有一個讀鎖定。

　　讀鎖定將阻塞一個寫鎖定；讀鎖定不會阻塞讀鎖定；寫鎖定將阻塞全部的讀寫鎖定。這就是爲何兩個框架中的同一個頁面都去寫同一個Session時，其中一個要等待另外一個（稍快的那個）完成後，纔開始寫。

　　可查看這裏http://www.bitsCN.com/article/9442.htm

　　/************************************************************/

　　「寫鎖定將阻塞全部的讀寫鎖定」，也就是說頁面在EnableSessionState="True"的狀況下沒返回輸出時，一直持着Session寫操做，其餘頁面對Session的讀操做必須等待，而asp.net的aspx頁面默認是EnableSessionState="True"，每一個頁面從請求開始至返回一直持着Session寫操做，需驗證頁面必須讀取Session值判斷，這就是爲何需驗證的頁面請求被阻塞的緣由。只要耗時頁面（A頁面）沒有Session的寫操做，也就不會阻塞其餘頁面的請求，因而修改A頁面的EnableSessionState="ReadOnly"，例如：<%@ Page Language="C#" AutoEventWireup="true" CodeFile="TBS_Monitor_List.aspx.cs" EnableSessionState="ReadOnly"  Inherits="TBS_Monitor_List" %> ，問題解決。