我們都知道，當服務器超過最大負載量的時候就不好使了。那么我們如何測試服務器有沒有超過最大負載量呢？

web應用服務器集群系統，是由一群同時運行同一個web應用的服務器組成的集群系統，在外界看來，就像是一個服務器一樣。為了均衡集群服務器的負載，達到優化系統性能的目的，集群服務器將眾多的訪問請求，分散到系統中的不同節點進行處理。從而實現了更高的有效性和穩定性，而這也正是基于Web的企業應用所必須具備的特性。

那么要如何計算WEB服務器最大負載量：

動態反饋負載均衡算法

動態反饋負載均衡算法考慮服務器的實時負載和響應情況，不斷調整WEB服務器間處理請求的比例，來避免有些服務器超載時依然收到大量請求，從而提高整個系統的吞吐率。圖1顯示了該算法的工作環境，在負載調度器上運行Monitor Daemon進程，Monitor Daemon來監視和收集各個服務器的負載信息。Monitor Daemon可根據多個負載信息算出一個綜合負載值。

Monitor Daemon將各個服務器的綜合負載值和當前權值算出一組新的權值，若新權值和當前權值的差值大于設定的閥值，Monitor Daemon將該服務器的權值設置到內核中的IPVS調度中，而在內核中連接調度一般采用加權輪叫調度算法或者加權最小連接調度算法。

連接調度

當客戶通過TCP連接訪問網絡訪問時，服務所需的時間和所要消耗的計算資源是千差萬別的，WEB服務器它依賴于很多因素。例如，它依賴于請求的服務類型、當前網絡帶寬的情況、以及當前服務器資源利用的情況。一些負載比較重的請求需要進行計算密集的查詢、數據庫訪問、很長響應數據流;而負載比較輕的請求往往只需要讀一個HTML頁面或者進行很簡單的計算。

請求處理時間的千差萬別可能會導致服務器利用的傾斜(Skew)，即服務器間的負載不平衡。例如，有一個WEB頁面有A、B、C和D文件，其中D是大圖像文件，瀏覽器需要建立四個連接來取這些文件。當多個用戶通過瀏覽器同時訪問該頁面時，最極端的情況是所有D文件的請求被發到同一臺服務器。

所以說，有可能存在這樣情況，有些服務器已經超負荷運行，而其他服務器基本是閑置著。同時，有些服務器已經忙不過來，有很長的請求隊列，還不斷地收到新的請求。反過來說，這會導致客戶長時間的等待，覺得系統的服務質量差。

簡單連接調度

簡單連接調度可能會使得服務器傾斜的發生。在上面的例子中，若采用輪叫調度算法，且集群中正好有四臺服務器，必有一臺服務器總是收到D文件的請求。這種調度策略會導致整個系統資源的低利用率，因為有些資源被用盡導致客戶的長時間等待，而其他資源空閑著。

實際TCP/IP流量的特征

文獻說明網絡流量是呈波浪型發生的，在一段較長時間的小流量后，會有一段大流量的訪問，然后是小流量，這樣跟波浪一樣周期性地發生。文獻揭示在WAN和LAN上網絡流量存在自相似的特征，在WEB服務器訪問流也存在自相似性。這就需要一個動態反饋機制，利用服務器組的狀態來應對訪問流的自相似性。