[]
[我要回覆]
|
|||||
|
|||||
樓主 站務人員 站長 
 發送站內信 
|
現在我們已經採納快取在應用程式和工作階段中的優點，而現在將建議避免使用工作階段物件。正如下面將討論的，當與忙碌的網站一起使用時，工作階段有幾個缺點。「忙碌」的意思一般是指一秒鐘要求幾百畫面或成千上萬同時使用者的網站。這個訣竅對於必須水平調適的網站 - 即那些利用多台伺服器以處理負載或建置容錯的網站 - 甚至更重要。對於較小的網站，諸如 Intranet 網站，工作階段的方便性是值得花成本的。 簡單地回顧一下，ASP 自動為每個存取 Web 伺服器的使用者建立一個工作階段。每個工作階段大約需要 10 KB 的記憶體虛耗空間 (除了存放在工作階段中的任何資料)，這就使所有的請求都減慢。在設定的逾時時段 (通常是 20 分鐘) 結束以前，工作階段一直保持有效。 工作階段最大的問題不是效能，而是調適性。工作階段不跨越幾台 Web 伺服器，一旦在一台伺服器上建立工作階段，其資料就留在那兒。這表示如果您在一個 Web 伺服器群使用工作階段，您必須設計一個策略，將每個使用者請求永遠導向到使用者工作階段所在的那台伺服器上。這被稱為將使用者「stick」在 Web 伺服器上。「Sticky 工作階段」一詞就是從這裏衍生而來的。如果 Web 伺服器當機，「stuck」使用者將遺失他們的工作階段狀態，因為工作階段不是存留到磁碟上。 建置 sticky 工作階段的策略包括硬體和軟體解決方案。諸如 Windows 2000 Advanced Server 中的網路負載平衡和 Cisco 的 Local Director 之類的解決方案都可以建置 sticky 工作階段，代價是要損失一定程度的調適性。這些解決方案是不完善的。不建議此時部署您自己的軟體解決方案 (我們過去常常使用 ISAPI 篩選器和 URL 轉換等等)。 應用程式物件也不跨越多台伺服器，如果您必須跨越 Web 伺服器群共用和更新應用程式資料，您必須使用後端資料庫。但是，唯讀應用程式資料在 Web 伺服器群中仍是有用的。 如果只是因為增加執行時間 (處理錯誤後移轉和伺服器維護)，大多數關鍵工作網站至少需部署兩台 Web 伺服器。因此，在設計關鍵工作應用程式時，必須建置「sticky 工作階段」，或幹脆避免工作階段，以及任何其它將使用者狀態存放在單一 Web 伺服器上的狀態管理技術。 如果您不使用工作階段，一定要將它們關閉。您可以透過 Internet Services Manager 來為應用程式關閉工作階段 (參閱 ISM 文件)。如果決定使用工作階段，您可以採用一些方法減輕它們對效能的影響。 您可以將不需要工作階段的內容 (如說明畫面、參觀者區域等等) 移到另一個已關閉工作階段的 ASP 應用程式中。您可以逐頁為在指定頁面中不需要工作階段物件的 ASP 提供提示，使用下面放在 ASP 頁面頂部的指令： <% @EnableSessionState=False %> 使用這一指令有一個很好的理由是工作階段會為框架組建立一個有趣的問題。ASP 保證任何時候都只執行工作階段的一個請求。這樣就確保如果瀏覽器為一個使用者請求多個畫面，一次只有一個 ASP 請求接觸工作階段，避免了當存取工作階段物件時發生的多執行緒問題。很遺憾，結果一個框架組中的所有畫面將以序列化方式顯示，一個接一個，而不是同時顯示。使用者可能必須等候很長的時間，才能看到所有的框架。該故事的寓意：如果某些框架組畫面不依靠工作階段，一定要使用 @EnableSessionState=False 指令告訴 ASP。 許多管理工作階段狀態的方法可以作為使用工作階段物件的取代辦法。對於少量的狀態 (少於 4 KB)，我們通常建議使用 Cookies、QueryString 變數和隱式變數。對於更大資料量，如購物籃車，後端資料庫是最適合的選擇。有關 Web 伺服器群中的狀態管理技術的文章很多。有關詳細資訊，請參閱工作階段狀態參考資料。
本篇文章發表於2000-09-09 00:00
|
||||
0
1580
542
9
