Web體系結構發展規劃

表 3. 一個在線購物站點當前和規劃中的評測結果

準確預測請求模式的能力是容量規劃的重要要求。我們的預測技術部分基于構建一套數學方法和模型，這些方法和模型用來分離并確定網站請求模式中的趨勢、相關性、季節效應、隨機性以及其他關鍵行為（請參見參考資料中的 4、6、7 和 8）。例如，這包括與長尾分布組合在一起的分段自回歸移動平均 (ARIMA) 的使用。圖 7是準備用于我們的模型的請求模式范例；該圖顯示了長野奧運會網站 1 小時內每秒接收到的請求數。從這些結果中擬合出的曲線顯示在數據點中間。

由于每個關鍵流量指數都可以在很大的范圍內變動，我們使用一套數學方法評估未來請求模式中每種指數的強度，并將其調整到預計的強度（請參閱參考資料中的 4、7 和 8）。然后，我們將這些調整后的數學模型結合在一起，以確定并預測請求模式。通過使用我們的數學方法隔離、確定并預測請求模式中的趨勢、相關性、季節效應、隨機性和其他關鍵行為，我們研究出一種一般的方法，這種方法能夠比當前采用的其他方法更準確、更有效地預測請求模式。

圖 7. 長野奧運會期間一小時內每秒的請求數

我們的方法已被實踐證明極為有效，已被用于預測短期和長期的實際站點請求模式。我們特意采用該方法對最近 IBM 主持的體育賽事站點的峰值小時請求容量進行了預測。在過去三年中，我們一直基于網站的請求模式以及 95% 的置信區間來作出評估。在其他方法中，我們采用了一階變化率方法評估每年的流量密度伸縮因數。我們通過對 1997、1998 和 1999 年的比較得出了指數式增長的趨勢。我們還使用 2000 年的預測伸縮因素，并結合我們調整 1999 年峰值小時流量模型的方法，預測出了 2000 年的峰值小時流量模型。結果與我們的預測相符：我們的預測與站點的實際峰值容量非常接近。另外，這些方法在預測將來季節性事件（如圣誕節在線購物高峰）的 請求模式方面也獲得了同樣的成功。我們還用此方法預測了短期（數天、數周）的請求模式；同樣，預測與站點的實際請求模式相當一致。

步驟 4. 確定基礎結構替代模型
您現在可以確定構建網站基礎結構所需的組件了�，F在您已經根據工作負荷模式的特定需求和目標確定了組件（也許在您的顧問或友好全球供應商的解決方案工程師的協助之下）。

IBM 正在為 HVWS 容量規劃開發的技術依賴于圖 8 中描繪的三種模型。

圖 8. HVWS 容量規劃模型

業務模型或業務使用模型定義了電子商務模式和工作負荷模式。每種工作負荷模式都有一個用戶行為模型。每種工作負荷模式包含幾類用戶請求。每一類的抵達模式和路由（轉換矩陣）站點訪問者都包含用戶行為模型。滿足每類用戶請求的軟硬件資源和數量包含基礎結構模型。

基礎結構模型處理瀏覽、搜索和購買交易。該模型假定：

• 網站有多層機器，每一層處理特定的一組功能，如圖9所示的站點。
• 負載均衡器（如網絡調度程序）采用一種算法將請求發送給多個前端 Web 服務器，以在這些服務器之間平均分配請求。
• 前端 Web 服務器處理對靜態或動態網頁的請求。
• Web 應用程序服務器處理請求所啟動的交易的業務邏輯。在圖9中，帳戶和報價服務器是應用程序服務器。
• 后端數據庫服務器處理對動態網頁的請求，這些網頁涉及獲取和更新信息；這類請求不通過負載均衡器返回。
  

圖 9. 多層網站（不包括防火墻層）

我們設計了一個排隊網絡的類，用以確定多層體系結構的模型，以便分析不同級別的性能。我們還進一步得出了這些模型在不同輸入流量模式和不同時間范圍內的多 種解決方案。這一系列數學模型和解決方案非常通用，足以抽象當前軟硬件的詳細信息，但它同時又非常詳細，足以生成有意義的性能結果。我們考慮一下排隊系 統，其中每層的資源由多服務器隊列模擬，這些多服務器隊列之間存在特定的關系。這些關系通過評測或評估的工作負荷指數確定。我們然后根據一組用戶需求解決 性能/容量問題，例如并發用戶數、響應時間或吞吐率。我們還制定了一個獨特的公式，使我們能夠評估系統處于以下狀態時的行為：峰值需求明顯高于平均需求， 而且不可忽略用戶訪問大量數據的概率。

我們的方法具有極大的靈活性，可根據用戶的需求和工作負荷指數確定水平和垂直方向的伸縮，或二者的組合。例如，我們可以通過添加另一臺服務器，或者在指定服務器上添加另一個處理器來增加 Web 服務器的數量。有了適當的網站和工作負荷數據，我們就能夠根據我們的性能模型和分析得到性能評估。

我們已為多家 IBM 托管的網站制定了容量規劃。圖 10就說明了這樣一個網站，并反映了采用當前的網站數據，然后根據當前的數據、趨勢和目標制定規劃來校正我們的模型的過程。在圖 10 中，前三個響應時間曲線反映了用于按步驟 2 中的方法校正模型的當前數據。通過分析當前的設計和組件信息，我們就可以對第四條曲線進行規劃。

參考圖 10，結果顯示當請求流量較小時，一臺前端服務器已足以處理負載。隨著流量的增加，響應時間曲線保持平直，直至該前端 CPU 的利用率達到 90%（每小時 280 萬次點擊）為止。這時，負載的少量增加就會導致系統很快死機，前端服務器以越來越低的速度嘗試處理越來越多的文件，這樣幾乎沒有人能感受到令人滿意的響應時間。這意味著前端服務器已成為瓶頸。因此，我們需要添加前端服務器，添加以后前端服務器的 CPU 利用率就會按我們的預期下降。響應曲線變成平直狀態，直至前端服務器的 CPU 利用率重新達到 90%（每小時 510 萬次點擊），這時我們需要考慮添加另一臺前端服務器。只有當大約 15 臺前端服務器每小時處理約 2800 萬次點擊時，后端服務器才會成為瓶頸。

圖 10. WebSphere 商務網站的伸縮

圖 11 中的圖形是我們在分析特定軟硬件組件的性能目標時得到的范例。

圖 11. 顯示性能指數的圖形范例。

小結
大容量網站的有效容量規劃是一件棘手的事情，但并非不可克服。我們在本文中提出的方法可以指導您了解工作負荷模式和當前設計，分析趨勢，設定未來的目標，并最終選擇能夠滿足您性能目標的 IT 基礎結構組件。分析特定工作負荷模式環境中的站點要求的能力對您作出正確的選擇很有幫助。

當然，容量規劃的課題還需繼續研究。越來越多的有價值的信息可供您使用（請參閱參考資料中的 10），令人振奮的新工具正在不斷出現，而且按需求提供容量的選擇也將極大地增強對流量增長作出反應的能力。IBM 的 HVWS 著眼于發現并總結現代的設計方法，以提供更大的容量和可伸縮性。該小組將繼續改進它的方法，開發包含該方法的工具，調整數學方法，并致力于諸如網絡高速緩存和快速增長的企業對企業工作負荷這類領域所提出的更多挑戰。在滿足未來需求的同時有效規劃并降低成本的前景十分廣闊。

文章來源于領測軟件測試網 http://www.kjueaiud.com/