Server Load Balancer環境下的ASP會話管理(2)

僅當web 範圍內的第一次點擊進行Server Load Balancer
這種方法也稱為前端Server Load Balancer，它易於描述，但是有可能不適於執行。為了實現真正的Server Load Balancer，每次
請求都要重新平衡使用者。但是在大多數情況下，前端Server Load Balancer就已經足夠滿足大部分這類伺服器維護的
支援者了。

        要實現這個目的，就只允許在範圍內的第一次點擊通過Server Load Balancer器。每個增加的頁面負載都將使用者保持
在同一個伺服器上。這就如同在代碼中使用相對路徑而不是絕對路徑一樣簡單。

< Form action="http://www.myserver.com/mypage.asp" method=post >

        變成

< Form action="/mypage.asp" method=post >

        在action 標記中使用相對路徑，使用者在訪問你的網站的整個過程中，都停留在同一個網路伺服器上。
這樣他們的session集合在同樣時間內與他們在一起。毫無疑問，這樣會使你的Server Load Balancer計劃受到
一定的損失，因為你只有一次機會決定在哪兒處理使用者的負載，並且在知道他們將產生多少通訊量
之前就要作出決定。但是在大多數情況下，因為允許使用sessions，這種方法已經接近於實現完全的
效能了。

        但是，這不是唯一的問題：在某些情況下，這不是一個合適的方法。例如，你的應用程式要求使用者離開
當前的伺服器，到一個專門用途的伺服器上，如email、搜尋或安全伺服器的話，這種方法就不行了。
另外，如果使用者把一個版面設定為書籤，或者試圖把這個URL 發送給朋友，他們可能要得到特定機器
的地址，進一步削弱你的Server Load Balancer計劃。最後，如果機器壞了，所有的使用者資訊都不可恢複地丟失了，
它沒有失敗恢複功能。



哪種方法最好？


        這個問題的答案可想而知：“看情況”。其它需要考慮的因素包括：

○ 你的網站點擊率有多高；
○ 你希望儲存多少狀態資訊；
○ 如果你有專門用途的伺服器；
○ 如果你想用第三方組件處理你的網站的寶貴部分。

        如果你的網站通訊量太大，那麼精確的Server Load Balancer對於網站的成功來說就非常重要，那麼不用sessions
編程，或使用Session Pro或 Microsoft的站台伺服器等第三方組件，是可行的。如果通訊量小，或者
只需要儲存較少的狀態資訊，那麼使用cookies 或僅僅前端Server Load Balancer就比較可行。

        總的來說，在建立網站之前你要充分考慮這些問題。決定採用什麼方法要把需要與網站的每個頁面相結合，
任何延遲都會導致主要部分的重做，也許會導致整個網站的完全重新構造。確定網站當前和將來會有什麼
需要，然後決定如何處理sessions的問題。