僅當(dāng)web 范圍內(nèi)的第一次點(diǎn)擊進(jìn)行負(fù)載平衡
這種方法也稱為前端負(fù)載平衡，它易于描述，但是有可能不適于執(zhí)行。為了實(shí)現(xiàn)真正的負(fù)載平衡，每次
請求都要重新平衡用戶。但是在大多數(shù)情況下，前端負(fù)載平衡就已經(jīng)足夠滿足大部分這類服務(wù)器維護(hù)的
支持者了。

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

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

變成

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

在action 標(biāo)記中使用相對路徑，用戶在訪問你的站點(diǎn)的整個(gè)過程中，都停留在同一個(gè)網(wǎng)絡(luò)服務(wù)器上。
這樣他們的session集合在同樣時(shí)間內(nèi)與他們在一起。毫無疑問，這樣會使你的負(fù)載平衡計(jì)劃受到
一定的損失，因?yàn)槟阒挥幸淮螜C(jī)會決定在哪兒處理用戶的負(fù)載，并且在知道他們將產(chǎn)生多少通信量
之前就要作出決定。但是在大多數(shù)情況下，因?yàn)樵试S使用sessions，這種方法已經(jīng)接近于實(shí)現(xiàn)完全的
性能了。

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



哪種方法最好？


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

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

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

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