台灣最大程式設計社群網站
線上人數
868
 
會員總數:245618
討論主題:189316
歡迎您免費加入會員
討論區列表 >> 專欄文章 >> 改善ASP效能的訣竅-16 (Nancy Cluts 著)
[]  
[我要回覆]
回應主題 加入我的關注話題 檢舉此篇討論 將提問者加入個人黑名單
改善ASP效能的訣竅-16 (Nancy Cluts 著)
價值 : 0 QP  點閱數:1953 回應數:0
樓主

站務人員 站長
門外漢
0 1580
542 9
發送站內信

捐贈 VP 給 站務人員
訣竅 16:在開始長途旅行之前使用 Response.IsClientConnected

如果使用者沒有耐心,他們可能會在您開始執行他們的請求之前就會放棄 ASP 畫面。
如果他們按一下重新整理或移到伺服器上的另一個畫面,
在 ASP 請求佇列的結尾就有一個新的請求等候,在佇列中間有一個中斷連線的請求。
當伺服器的負載很高時 (因此請求佇列就會更長,回應時間也會相應地變長),就會經常發生這種情況,這樣只能使情況變得更糟。
如果使用者不再連線,執行 ASP 頁面 (特別是慢的、大的 ASP 頁面) 已沒有任何意義。
您可以使用 Response.IsClientConnected 內容檢查這個情況。如果它傳回 False,則應呼叫 Response.End 並放棄畫面的其餘部分。

事實上,IIS 5.0 已將這個做法編碼 - 每當 ASP 即將執行新請求時,它就會檢查請求在佇列中已等候多長時間。
如果已經在那媯平啈h於 3 秒鐘,ASP 將檢查用戶端是否仍處於連線狀態,如果沒有連線,就立即停止請求。
您可以在 metabase 中使用 AspQueueConnectionTestTime 設定來調整 3 秒的逾時。

如果畫面要花很長時間才能執行完,您可能想要不時地檢查 Response.IsClientConnected。當啟動回應緩衝時,最好不時地執行 Response.Flush,讓使用者知道正在發生什麼事。

注意 在 IIS 4.0 上,除非先執行 Response.Write,否則 Response.IsClientConnected 就不能正常運作。
如果啟動緩衝,您也必須執行 Response.Flush。
在 IIS 5.0 上,卻沒有必要這樣做,- Response.IsClientConnected 運作正常。
在任何情況下,Response.IsClientConnected 都會有一些成本,因此只有在一個作業至少要花 (比方說) 500 毫秒時 (如果您想維持每秒鐘數十頁的輸送量,這是一個很長的時間) 才使用它。
經驗證明,不要每次重複執行緊密迴圈時都呼叫它,如顯示資料表的許多資料列時 - 每隔二十或五十資料列可能比較合適。

本篇文章發表於2000-09-09 00:00
目前尚無任何回覆
   

回覆
如要回應,請先登入.