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

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

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

變成

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

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

但是，這不是唯一的問題：在某些情況下，這不是一個合適的方法。例如，你的應用程序要求用戶離開
當前的服務器，到一個專門用途的服務器上，如email、搜索或安全服務器的話，這種方法就不行了。
另外，如果用戶把一個頁面設置為書簽，或者試圖把這個URL 發送給朋友，他們可能要得到特定機器
的地址，進一步削弱你的負載平衡計劃。最后，如果機器壞了，所有的用戶信息都不可恢復地丟失了，
它沒有失敗恢復功能。



哪種方法最好？


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

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

如果你的站點通信量太大，那么精確的負載平衡對于站點的成功來說就非常重要，那么不用sessions
編程，或使用Session Pro或 Microsoft的站點服務器等第三方組件，是可行的。如果通信量小，或者
只需要保存較少的狀態信息，那么使用cookies 或僅僅前端負載平衡就比較可行。

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