電子商務的增長使得以下一點變得至關重要，那就是必須確保支持網站的 IT 基礎結構能夠為公司的信息、產品和服務提供可用、可伸縮、快捷以及高效的訪問。CIO 及其小組面臨著前所未有的挑戰，那就是必須將停機時間和網絡瓶頸降至最低程度，并最充分地利用構成其電子商務基礎結構的軟硬件。

支持最大容量網站 (HVWS) 的 IT 基礎結構一般包括多層機器，常常稱為層 (tier)，如圖 1 所示。每層包含多臺機器（從兩臺到數百臺）來提供該層上所運行功能的容量和可用性。每層提供一組特定的功能，例如提供內容（Web 表示服務器）、提供集成業務邏輯（Web 應用程序服務器）或處理數據庫事務（事務和數據庫服務器）。

圖 1. 電子商務的多層基礎結構

雖然復雜性越來越高，但仍可以分析典型的 IT 基礎結構并開發相關的模式，以協助對如何滿足未來需求作出預測和規劃。

容量規劃方法
IBM 的 IT 專家一直與 IBM 的多家客戶合作，對大型網站進行分析并幫助客戶實施可伸縮的網站（請參閱參考資料中的 1）。部分客戶已在同 IBM 共同利用和促進開發中的容量規劃技術。我們的方法基于這一正在進行的研究（參考資料中的 4、5、6、7、8、9）以及 IBM 的電子商務模式。

我們的容量規劃方法基于對多家大型網站（包括 IBM 的網站）的分析，以及我們與那些尋求改進網站性能、精確地規劃工作負荷、進行基礎結構更改以滿足未來需求的的大型客戶的不斷接洽。該方法包括以下四個步驟：

1. 確認您的工作負荷模式。
2. 評測當前站點的性能。
3. 分析趨勢并設定性能目標。
4. 確定基礎結構替代模型。

無論您是在考慮更改當前站點還是規劃新網站，這些步驟都同樣有效。

本文將集中介紹容量規劃技術。實施這些技術將影響您的 IT 組織、流程和人員；本文并不涉及這些相關的含義。

我們小組的容量規劃技術是對 IBM 的電子商務模式的補充（請參閱參考資料），因為您可以將我們描述的每種工作負荷模式對應到站點設計的一種電子商務模式。無論您使用哪些方法設計您的站點，這種容量規劃方法都可作為那一工作的補充，并為管理您的容量需求打下基礎。

步驟 1. 確定您的工作負荷模式
因為容量規劃主要是大容量網站的問題，所以在本文中我們將假定您的工作負荷容量大而且正在增長，而且需要提供動態數據并處理交易。除此之外，您必須考慮到其他指數，例如交易復雜性、數據變更率及安全性。在進行分析以后，您就可以將工作負荷模式分為 5 類：發布/預訂、在線購物、客戶自助式服務、交易、或企業對企業。適當地確定您的工作負荷模式可確保我們的方法中的其余步驟獲得最佳結果，并使您的網站能最大程度地滿足未來的需求。（如果您以前是按我們小組的系列論文做的，則您無須檢查工作負荷模式，并可跳至步驟 2。）

請參考以下的工作負荷模式說明（或參閱工作負荷模式概覽以了解其本質，并將其匯總到表格中）來確定您的工作負荷模式：

• 發布/預訂網站為用戶提供信息。 發布/預訂站點范例包括搜索引擎、媒體站點（如報紙和雜志）以及事件站點（例如奧運會和溫布爾登錦標賽）。站點內容會頻經常繁變化，從而促使網頁布局不斷 變化。盡管搜索量小，但搜索到的唯一項目很多，這就是此類站點在所有站點類型中頁面訪問量最大的原因。例如，悉尼奧運會網站（WebSphere 環境）成功地處理了每分鐘 120 萬次點擊的訪問量（有關 WebSphere 的信息請參閱參考資料）。與其他站點類型相比，安全性不是大問題。數據變更率較低。這種站點類型處理的交易最少，很少或者根本不連接任何舊有系統。
• 在線購物站點允許用戶瀏覽和購買。 站點范例包括用戶購買書籍、衣物甚至汽車的典型零售站點。站點內容相對固定 — 例如部件目錄 — 或動態變化（例如，隨著促銷和特殊折扣活動的開始和結束，項目被頻繁添加和刪除）。搜索流量比發布/預訂站點大，但搜索到的唯一項目數不是很大。數據變更率較低。交易流量處于中上水平，并幾乎始終在增加。許多大型零售客戶的典型日容量從每天不到 100 萬次點擊到每天超過 1300 萬次點擊，交易量從每天 10 萬次到 300 萬次；在交易總數中，1% 到 5% 為購買交易。當用戶購買時，安全性要求變得至關重要，包括隱私、認可、完整性、驗證和規則。與發布/預訂站點相比，購物站點與舊有系統（例如履行系統）的連接稍多，但通常比其他站點類型與舊有系統的連接要少。
• 客戶自助式服務可使用戶自我服務。 站點范例包括在家進行銀行業務、跟蹤包裹以及安排旅行。數據大量來自舊有應用程序，而且一般有多種來源，因此數據一致性較差。安全性考慮對于在家進行銀行業務和購買旅行服務至關重要，對于其他用途則沒那么重要。搜索流量較??；交易流量處于中等水平，但在不斷增長。
• 交易站點允許用戶進行買賣交易。在所有站點類型中，交易站點的內容變更率最高，交易量最大（擺動幅度大），交易復雜程度也最高。交易站點還對時間極為敏感。交易站點與舊有系統緊密連接，使用 IBM 的 MQSeries 等軟件提供連通性。幾乎所有的交易都與后端服務器交互。安全性要求較高，與在線購物相同，安全網頁數更多。搜索流量較低。
• 企業對企業站點允許企業間開展買賣業務。 數據大量來自舊有應用程序，而且一般有多種來源，因此數據一致性較差。 安全性要求與在線購物相同。交易量為中等，但一直在增長；交易通常較為復雜，需要連接多個供應商和分銷商。此模式有兩種類型：
• • 企業對企業的集成：這種類型包括公平交易之間的計劃性連接（可能需要業務伙伴簽訂協議）。供應鏈管理就是一個例子。
  • 電子市場或 B2M2B： M 代表電子市場，支持多個買方和供方。購買功能可在線或有計劃地進行。

我們對多種工作負荷模式下電子商務基礎結構性能的分析說明了以下這一點：工作負荷模式的復雜性（例如突增抵達模式）可極大地影響資源需求、吞吐量和用戶請 求的延遲時間，具體表現在更高的平均響應時間和更大的響應時間差異。如果沒有最佳的適應性資源管理和控制，基于響應時間的服務級協議 (SLA) 就無法實現。站點的容量要求不斷提高，而其提供可接受的性能和可用性的能力卻在降低。

在分析您的當前站點時，要記住將網頁的設計考慮在內。IBM 的研究表明您可以遵照許多慣例來減少您的網頁的下載時間。網頁都具有相同的組件和指數，如頁面大小和項目數，因此，您可以而且應該著眼于將其下載時間降至 最低程度。做“正確”的事并不是總能成功，而且有些組件或指數是網頁設計員無法控制的。另外，對站點性能感興趣的人員都應該了解這些因素以及其相關的負面 影響。表 1 匯總了 15 個不同網站的頁面設計。設計各不相同，但都強有力地表明網頁設計是一個重要的性能成分；如果管理得當，則它們可以提高網站的容量。在這個彩色的表中，良好 或優秀的設計標為綠色；稍差的設計標為琥珀色，而很差的設計標為紅色。有關優化您的網頁以便加快下載的詳細信息，請參閱我們小組的前一篇論文，" Design pages for performance"。

表 1. 網頁設計范例。綠色表示良好；紅色表示很差；琥珀色表示勉強。

每個類別是按照請求抵達網站的方式以及滿足請求所需的資源來劃分的。影響抵達的主要因素包括標準（臨界）分布、相關性結構和季節性?？傊?，IBM 的分析表明，復雜行為包括短尾和長尾分布、短距離和長距離的相關性、強季節性和周期性以及地理效應。在這些條件下，站點請求的獨立指數輸入時間間隔這一典型假定不成立，所以必須采用非傳統假定來解決問題，這需要復雜的數學算法。IBM 對這些指數的數學研究使人們能夠開發更好的模型，以便了解并預測這些關系和行為的影響。

圖 2. 每種工作負荷模式都有相關的一類用戶請求

分布和相關性
Web 流量顯示了突增、長尾和相關的抵達模式。流量突增指請求的隨機到達，其高峰期的流量遠遠超過平均水平。這種突增現象由不可預測的事件（如股市動蕩）或特殊 事件（如圣誕節和情人節）引起。這些事件會產生請求間的相關性（例如，更大的突增易于在鄰近的地方發生）、長尾分布（例如，流量增長的波動幅度極大）以及 相關性和長尾分布的結合。隨機變量的長尾分布是指分布曲線的尾端呈指數下降。對于這些分布，會產生極大一個值。成批抵達過程顯示了這種長尾行為，并且成批 請求的大小趨向于密切相關。在容量規劃中，獲得流量突增、長尾和相關抵達的實際結果并非易事。

突增和變化極大的點擊率是影響站點性能和可用性的最顯而易見的工作負荷模式復雜性之一。在傳統模型中，各個請求相互獨立，流量突增幅度的變化相對較小。這些分布屬于短尾分布類。HVWS 的流量突增引起了長尾分布和強相關性結構。1998 年長野奧運會的流量模式恰好說明了這一點，如圖 3 所示。這種請求突增是由某些特殊事件引發的，例如，在這次奧運會上，日本獲得了跳高滑雪項目的金牌。請比較亞洲的長尾分布和當日歐洲的短尾分布之間的差異。另外，請注意每天、一天中以及不同地點間的獨立性結構。

圖3. 1998 年長野奧運會流量模式

IBM 的 Wimbledon 2000 網站也在最忙碌的一天，2000 年 7 月 7 日，顯示出極度突增現象。
圖 4 繪制了那天的破記錄站點流量，當時的每分種峰值點擊次數達到 963,948 次，且每天峰值點擊次數總計達到 281,605,872 次。

圖 4. 破記錄那天 IBM 的 Wimbledon 網站

非傳統請求流量對 Web 服務器造成壓力。長尾分布的流量突增所產生的性能下降要比短尾分布所產生的性能下降大幾個數量級。與短尾模型相比，長尾分布發生極端流量突增的情況更頻 繁。另外，相關性結構可導致在鄰近的地方發生流量突增現象。對于這種輸入流量特性，性能評測結果，尤其是響應時間，與輸入流量具有相似的指數。這有助于解 釋為什么一些體育和電子商務網站比相對簡單的網站（例如只提供靜態內容的大學網站）更難維護。

就 SLA 而論，長尾分布的同級服務比獨立的短尾請求流量要求具備更為強大的一組服務器。為了確保獲得優良的性能，您必須注重流量的高峰期，因為請求的巨增是導致性能降低的首要元兇。這有些繁忙站點需要更多的峰值儲備空間（空閑容量）來處理這些容量，例如大容量在線貿易站點用 3:1 的比例來保留空閑容量。

季節性
季節性是指請求模式的周期性。季節流量主要由網站用戶的正常日活動量來表示。例如，每天當開盤和收盤時，一些電子交易網站都有一致的交易高峰期和低谷期。季節性流量也可以按月觀測，例如，在用戶月終付款時，或在指定周期（例如節假日）內。

圖 6 顯示長野奧運會網站季節性流量范例。該圖繪制了從 2 月 9 日到 16 日間每 5 分鐘內所有服務器接收的請求數。盡管每天的周期變化很大，但請注意每天包含三個峰值，總體流量密度在每個工作日開始增加，然后在周末減少。這些模式每周反復，說明了與周周期對應的季節性變化。

圖 5. 用長野奧運會一周的流量來說明的季節性范例

季節性請求會降低 Web 服務器的性能，因為在高峰期內，同一時間內將會出現大量的請求。關鍵問題在于這個峰值有多“高”，以及高峰期會持續多長時間。這兩個問題的答案對 Web 服務器的功能應有多強才能有效處理特定的 SLA 有極大的影響。為了圓滿處理請求流量，Web 服務器的容量應該與峰值請求時的容量接近，并且還要留出一定的峰值貯備空間，以防意外的增長。

確定工作負荷模式的其他因素包括頁面瀏覽量和交易量、搜索的容量和類型、交易復雜性、數據變更率以及安全性考慮。

本節后面的內容將介紹可用來獲取完成容量規劃所需的評測結果的方法。

獲取站點評測結果
每種工作負荷模式都需要特定的評測方法。表 2 提供了一個在線購物站點當前的評測結果方法范例，“當前”的評測結果將用作規劃基準。

表 2. 一個在線購物站點的基準評測方法范例

通過分析典型的用戶訪問，就能夠創建未來用戶訪問的概率。例如，在線購物者通常都是在瀏覽，也可能查詢，偶爾會購買。您可以開發各種腳本來描述用戶的訪問。腳本 1、2 和 3 包含所有適用于您的情況的在線購物、在線銀行和在線交易方案的腳本范例。

腳本 1. 在線購物方案的腳本范例

腳本 2. 在線銀行方案的腳本范例

腳本 3. 在線貿易方案的腳本范例

借助方案腳本和評測結果中的數據，您就可以創建一種轉換矩陣。圖 6 是在線購物訪問的轉換矩陣范例。通過查看與腳本范例相關的轉換矩陣，可以很容易看出瀏覽和搜索請求；當用戶決定 添加（到購物袋）并付款時，就產生買賣請求。

圖 6. 在線購物訪問的轉換矩陣范例

步驟 3. 分析趨勢并設定性能目標
您的網站工作負荷正在不斷增長，當前的設計無論有多么優秀都必須改進 — 同時必須改進的還有構成基礎結構的軟硬件的能力。在這一步驟中，您要分析趨勢以確定未來峰值容量的指數，然后為步驟 2 中確定的每種設計設定目標，并采用適用于未來需求的任何新設計。表 3 提供了一個在線購物站點當前以及規劃中的評測結果范例。性能目標一般受業務目標推動，例如：縮短對首選客戶的響應時間。

表 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 著眼于發現并總結現代的設計方法，以提供更大的容量和可伸縮性。該小組將繼續改進它的方法，開發包含該方法的工具，調整數學方法，并致力于諸如網絡高速緩存和快速增長的企業對企業工作負荷這類領域所提出的更多挑戰。在滿足未來需求的同時有效規劃并降低成本的前景十分廣闊。

參考資料（序號與正文的引用對應）

• IBM 大容量網站小組的其他論文：

• Patterns for e-business site 可幫您全面了解如何規劃復雜的網站體系結構，并為這一過程提供決策支持。