引言 網(wǎng)站建設的發(fā)展使得保證支持)*+站點的,- 基礎結構能夠為訪問公司的信息、產(chǎn)品和服務提供可用、可擴展、快速且高效的途徑成為了關鍵任務。 規(guī)劃網(wǎng)站時必須確保網(wǎng)絡及其組件能夠處理將來訪問站點的用戶數(shù)量。容量規(guī)劃是一個長期過程。它需要不斷監(jiān)視服務器的使用情況，以確保有足夠的資源來保證客戶的訪問。隨著時間的推移，大多數(shù)規(guī)劃都會碰到用戶數(shù)量和訪問的內(nèi)容總量大大增加的情況。當高峰用戶數(shù)量訪問網(wǎng)絡上的應用程序和服務時，容量規(guī)劃對于確保系統(tǒng)能夠充分運行至關重要。因此必須充分規(guī)劃網(wǎng)站，使其能夠瞞足最大數(shù)量用戶同時訪問網(wǎng)站的請求，并在此基礎上確保網(wǎng)絡的硬件和軟件容量能夠滿足預期需求。本論文介紹容量規(guī)劃所涉及的有關問題，以及如何規(guī)劃網(wǎng)絡的容量要求。 1、容量規(guī)劃的簡介 任何網(wǎng)站的目標都是向用戶提供優(yōu)質(zhì)的服務。當用戶遇到反應速度慢、超時和錯誤、鏈接斷開等問題時，他們會失去耐心，并轉向其他網(wǎng)站去查找所需內(nèi)容。要防止這一點，就必須提供一個不但能處理常規(guī)需求水平，而且能處理高峰需求水平甚至更高水平的基礎結構。容量規(guī)劃讓我們能夠計算滿足用戶需求所需的硬件要求。這類計算可以使我們識別在網(wǎng)絡設計中造成性能降低和導致服務質(zhì)量降低的瓶頸，然后我們可以修改設計或根據(jù)需要做出更改來解決瓶頸問題。 網(wǎng)站容量是由用戶數(shù)量、服務器容量、硬件和軟件配置、以及網(wǎng)站內(nèi)容來確定。容量規(guī)劃可被表述為一個簡單等式：支持用戶數(shù)量. 硬件容量/ 硬件的人均用戶負載在這個等式中，支持用戶數(shù)量指同時訪問的用戶數(shù)量，硬件容量指服務器和網(wǎng)絡容量，硬件的人均用戶負載是指訪問用戶的人均硬件開銷。容量規(guī)劃通常基于兩個概念： (1)降低每位用戶給硬件增加的負載，這可以通過對網(wǎng)站內(nèi)容進行規(guī)劃、程序設計和配置可以更加有效地利用現(xiàn)有資源。 (2)配置網(wǎng)站的基礎結構以增加硬件容量，方式有硬件擴展（增加服務器數(shù)量）或升級（將現(xiàn)有服務器升級）。 如果網(wǎng)站內(nèi)容復雜性提高了，那么就增加了人均用戶的硬件負載，但仍然要保持可支持的用戶數(shù)量，那么就必須增加硬件容量。這可以通過擴展和升級兩種方法解決；如果希望能夠支持更多的用戶，就需要增加硬件容量或降低硬件的人均用戶負載。 通過統(tǒng)計訪問網(wǎng)站的用戶數(shù)量并測量每位用戶對服務器的需求，然后對支持當前和將來使用水平的計算資源（CPU、RAM、磁盤空間和網(wǎng)絡帶寬）進行計算，這樣可以確定網(wǎng)站的容量水平。 2、容量規(guī)劃過程中應考慮的幾個因素 容量規(guī)劃所涉及的幾個因素： 2.1 通信 當瀏覽器向WEB 服務器發(fā)出請求時，瀏覽器首先會與服務器建立一個傳輸控制協(xié)議（TCP）連接。然后瀏覽器通過該連接發(fā)出請求，服務器則相應請求發(fā)出頁面，這種輸入請求與輸出相應的互換被稱為通信。通信不可完全預測。比如，有很多站點可能經(jīng)歷過工作日開始及結束時的活動高峰，而中間那段時間的活動水平則較低。另外，每天的高峰規(guī)模也會有所不同。通信量與支持通信所需的網(wǎng)絡帶寬之間也存在直接的聯(lián)系。站點訪問者越多，服務器提供的頁面就越多，從而就要求更多的網(wǎng)絡帶寬。 2.2性能 WEB應用程序的性能對于確定網(wǎng)站的容量至關重要。確定WEB應用程序的容量和性能的唯一方法是進行測試。常用的測試工具有：公用程序WEB容量分析工具（WCAT）和WEB應用程序STRESS 工具（WAST)。 2.3可用性 可用性是規(guī)劃網(wǎng)絡容量要求時需要考慮的重要因素。首先必須確定要獲得什么類型的可用性。爭取達到多高的程度？這取決于公司打算投入多少財力來保證網(wǎng)絡始終能夠滿足高峰容量需求？必須確定的一點是因網(wǎng)站不可用而引起的問題是否能抵消為此聯(lián)機狀態(tài)所支付的費用。 2.4伸縮性 準備對網(wǎng)站進行升級以提高其可用性、增加同時用戶數(shù)量、或減少網(wǎng)站等待時間加快響應時間時，網(wǎng)站的伸縮性是需要考慮的首要因素。網(wǎng)站的伸縮性與可用性機密相連。網(wǎng)站升級不應該產(chǎn)生無計劃或不必要的停機時間。 3.規(guī)劃網(wǎng)絡容量步驟： 3.1確定站點的用途和類型 開始規(guī)劃站點的容量需求之前，您必須確定站點的用途，以及要創(chuàng)建什么類型的站點。例如，要創(chuàng)建一個事務處理站點，以允許用戶檢索并存儲信息，一般是在一個數(shù)據(jù)庫中。事務處理站點涉及可靠性和安全性要求，而其他類型的站點則沒有這樣的要求。除確定站點類型之外，必須確定站點是否要支持某些形式的動態(tài)內(nèi)容。動態(tài)內(nèi)容有很多形式，而且各種不同的,INTERNET 及數(shù)據(jù)庫技術都提供動態(tài)內(nèi)容，如SQL、ASP或CGI。簡單來說，動態(tài)內(nèi)容涉及到WEB 服務器與數(shù)據(jù)庫聯(lián)系、檢索數(shù)據(jù)、將數(shù)據(jù)格式化、然后作為)WEB頁面發(fā)送到用戶的瀏覽器上。例如，如果一位用戶要查看某個特定產(chǎn)品的信息，服務器就會聯(lián)系SQL Server數(shù)據(jù)庫以檢索該產(chǎn)品說明、照片、價格信息，以及該產(chǎn)品是否還有庫存。檢索結果會以常規(guī)的HTML頁面顯示在用戶的瀏覽器上，就像一個靜態(tài))WEB頁面，但它卻是服務器在用戶發(fā)了請求時在運行過程當中創(chuàng)建中。使用動態(tài)內(nèi)容的站點比靜態(tài)站點需要的處理容量要多得多。 3.2確定用戶基數(shù) 下一步是計算)WEB站點的容量，以確定同時使用站點的用戶數(shù)量。這個數(shù)字通常有兩個主要來源：市場分析和系統(tǒng)分析。 如果站點還未建立或發(fā)布，站點所有者和操作人員就可能需要借助市場分析報告來預測站點發(fā)布初期及以后的預期通信量。如果站點已經(jīng)建立且已在運行，分析WEB服務器的日志文件，以了解站點在不同時間的點擊數(shù)以及可以表明站點內(nèi)容受歡迎程度是否增加的所有使用趨勢。計算站點當前支持的用戶數(shù)量時，要根據(jù)高峰使用來計算，而不是根據(jù)典型使用或平均使用。 3.3確定硬件需求 通過預測站點某一段時間的訪問者數(shù)量或統(tǒng)計一段時間的實際訪問者數(shù)量并將該數(shù)據(jù)與硬件容量相比較,您可以確定站點的硬件需求。 3.3.1 CPU需求 WEB應用程序受處理器約束。多個線程試圖執(zhí)行相同的關鍵部分或訪問相同資源可導致資源爭奪問題，從而導致頻繁的環(huán)境轉換并在吞吐量很低的時候也使CPU處于忙碌狀態(tài)。如果多數(shù)線程阻塞，如等待數(shù)據(jù)庫時，就還有可能出現(xiàn)CPU利用很低，吞吐量也很低的情況。 可以通過兩個基本方式獲得所需處理能力：向每臺服務器添加更多的處理器，或者添加服務器。與添加服務器相比，向現(xiàn)有服務器添加處理器的成本更低（也更更簡單）。但對于多數(shù)應用程序來說，添加處理器到一定程度時就不起作用了。另外，操作系統(tǒng)支持的處理器數(shù)量也有限。 添加服務器可以將群集線性擴展到您所需要的大小。（線性擴展就是說兩臺服務器可處理兩倍于一臺服務器可處理的負載，三臺服務器可處理三倍的負載，九臺服務器呆處理九倍的負載，以此類推。） 3.3.2內(nèi)存需求 RAM存?。s10毫微秒）大約比磁盤存?。s10毫秒）快一百萬倍，所以每次將一個頁面交換到內(nèi)存中時，就是在降低應用程序的速度。添加充足的RAM對任何系統(tǒng)來說都是獲得最佳性能最好、最經(jīng)濟的辦法。而且您可以通過檢查分頁計數(shù)器（應用程序一旦開始運行，分頁活動就應當很少）來保證應用程序有足夠內(nèi)存。 3.3.3存儲需求 隨著企業(yè)網(wǎng)絡不斷增長. 網(wǎng)絡存儲解決方案正在日漸成為人們的選擇。每個公司在選擇數(shù)據(jù)存儲的介質(zhì)和方法時都有不同的考慮。有些公司受制于成本，而有些公司則著重考慮性能。在評估存儲需求時，需要將可提供高可用性的存儲系統(tǒng)的成本與可能出現(xiàn)的數(shù)據(jù)損失、生產(chǎn)率、商業(yè)等因素相比較。制定存儲管理策略之前，應考慮下列需求： ·對公司來說成本最合算的技術 ·可以滿足網(wǎng)絡發(fā)展需求的充足的存儲容量 ·對小時訪問重要數(shù)據(jù)的需求 ·數(shù)據(jù)存儲的安全環(huán)境 在尋找成本最合算的解決方案時，需要在購買并維護軟硬件的成本和出現(xiàn)災難性數(shù)據(jù)損失的后果之間進行權衡。成本包括下列費用： ·硬件方面的初期投入，如磁帶和磁盤驅動器、電源供應、控制器 ·相關介質(zhì)，如磁帶和光盤 ·軟件，如存儲管理工具和備份工具 ·當前的軟硬件維護費用 ·人員配備 ·如何使用新技術方面的培訓 ·脫站存儲設備 將上述費用與下列費用做比較： ·更換文件服務器、郵件服務器或打印服務器的費用 ·更換運行SQL Server或系統(tǒng)管理服務器（Systems Management Server）的費用 · 更換運行路由和遠程訪問服務（Routing and Romote Access Server ,RRAS）、SNA Server、Proxy Server或Novell Net Ware的費用. ·為不同部門的人員更換工作站的費用 ·更換個別計算機組件如硬盤或網(wǎng)絡卡使用 選擇存儲系統(tǒng)時需要考慮的另一個重要因素是數(shù)據(jù)恢復的速度。如果服務上的數(shù)據(jù)丟失，多快能夠恢復數(shù)據(jù)？在故障開始嚴重影響到公司業(yè)務之前，您能夠承擔的服務器（或整個網(wǎng)絡）故障時間有多長？ 存儲技術發(fā)展迅速，所以在作出采購決定之前，最好對各種類型的相關優(yōu)點都有所了解。要使用的存儲系統(tǒng)應該具備比備份關鍵數(shù)據(jù)所需容量還要高的容量。而且這個存儲系統(tǒng)還應該能夠在備份和恢復操作過程中執(zhí)行錯誤檢測和更正。 3.3.4數(shù)據(jù)服務器和磁盤需求 數(shù)據(jù)庫是一個潛在的瓶頸，一旦有問題會很難修復。讀E 寫實時數(shù)據(jù)必須有一份完全相同的數(shù)據(jù)副本，所以增加數(shù)據(jù)庫容量更有難度。有時瓶頸可能在數(shù)據(jù)庫服務器上，有時又可能在磁盤陣列中。 如果問題在服務器的CPU 容量方面，則可通過添加CPU來解決。數(shù)據(jù)庫應用程序如SQL SERVER可充分利用新增處理器；如果磁盤是瓶頸，則可采用更快的磁盤陣列。若數(shù)據(jù)庫應用程序可利用高級緩存技術，添加RAM也會有所幫助。 另外一個選擇是將數(shù)據(jù)庫分配到多個服務器上。首先可將目錄數(shù)據(jù)庫放到一臺服務器或一組服務器上。因為目錄通常是只讀的，復制數(shù)據(jù)會很安全。其次可以將經(jīng)常閱讀的數(shù)據(jù)如客戶信息進行分段或將讀E 寫數(shù)據(jù)分段，這樣可加快數(shù)據(jù)庫的訪問速度。 3.4確定網(wǎng)絡帶寬 一旦確定了特定時間要支持的用戶數(shù)量，就有了網(wǎng)絡連接帶寬的下限，能夠支持常規(guī)負載和使用尖峰。但站點類型在很大程度上影響到這個問題。例如，如果網(wǎng)站在很大程度上是基于用戶或完全基于用戶，或者站點只是在內(nèi)聯(lián)網(wǎng)上或是內(nèi)聯(lián)網(wǎng)結合外聯(lián)網(wǎng)，可以估算最大尖峰時刻的網(wǎng)絡帶寬。硬件聯(lián)網(wǎng)后可能存在若干潛在瓶頸。首先，對于您所發(fā)送的所有數(shù)據(jù)來說，網(wǎng)絡與Internet的連接可能不夠快。如果應用程序很受歡迎，您就可能需要速度更快的連接或使用冗余連接。冗余連接也可以增加站點的可靠性和可用性。通過減少發(fā)送的數(shù)據(jù)量，特別是圖形、聲音、和視頻，可以降低對帶寬的需求，從而防止瓶頸發(fā)生。如果您的防火墻不能夠快速處理通信量，也會成為瓶頸。需要注意的一點是以太網(wǎng)絡不能以接近其理論容量的水平運行，因為這會產(chǎn)生很多沖突（兩個發(fā)送機試圖同時發(fā)送）。發(fā)生沖突時，兩個發(fā)送機在重新發(fā)送之前都必須等待一段時間。有些沖突無法避免，但隨著網(wǎng)絡趨于飽和，沖突會迅速增加，這樣您就幾乎沒有有效帶寬了。 使用交換機（而不是使用集線器）將網(wǎng)絡互連可大大減少沖突。交換機直接連接兩個端口，而不是將通信傳播到所有端口，所以多對端口可以通信而不發(fā)生沖突。與集線器相比，交換機則是不錯的選擇。 3.5查找潛在瓶頸問題 通常在網(wǎng)絡出現(xiàn)擁塞之前，盡可能提前查找那些潛在的隱蔽的瓶頸問題，找出那些可能最先出現(xiàn)問題的地方。查找潛在瓶頸可遵循下列步驟： (1)畫出標示所有進入站點路徑的方框圖，包括：如到FTP下載站點的鏈接、其他URL等。 (2)確定容納各個功能組件（數(shù)據(jù)庫、郵件、FPT等等）的機器是什么。 (3)畫出站點網(wǎng)絡模型和到它的環(huán)境的連接。確定吞吐量，確定鏈接的速度。 (4)為每個頁面創(chuàng)建一個回答下列問題的用戶配置文件： · 用戶停留在該頁面上的時間有多長？ · 哪些數(shù)據(jù)傳送到該頁面上或該頁面?zhèn)魉土四男?shù)據(jù)？ · 該頁面生成多少數(shù)據(jù)庫活動（或其他活動）？ · 每個頁面上有什么對象？這些對象對系統(tǒng)的友善程度有多高？（即這些對象加在系統(tǒng)資源上的負載有多重？如果這些對象出現(xiàn)問題，有沒有影響到其他對象或應用程序？） (5)定哪些是客戶端對象，哪些是服務器端對象。 3.6更新WEB站點 在確定了站點每臺服務器可支持的用戶數(shù)量以后，可以考慮站點的擴展問題，以支持更多用戶或向現(xiàn)有用戶提供更好的服務。 下列基本策略可用來更新站點： · 提高每臺服務器可支持的用戶數(shù)量 · 提高站點可支持的同時用戶的數(shù)量 · 縮短站點的延遲時間，以提高響應速度 您可以選用下列一種或多種方式來實施上述策略： · 優(yōu)化內(nèi)容重新設計動態(tài)內(nèi)容，以減輕站點體系結構負擔。可以編寫更智能（smarter）的ASP或更改站點，以降低普通用戶調(diào)用重Cheavy ASP的次數(shù)。 · 提高服務器性能（升級）添加速度更快的&’( 和內(nèi)存；升級到速度更快的軟件，如從windows NT 升級到Windows 2000；并通過優(yōu)化配置來調(diào)節(jié)服務器。 · 添加服務器（擴展）向@6: 群集添加更多的服務器。采取這些措施之前以及之后通過分析站點來測量改變之后的效果，然后比較結果。這也有助于預測未來可能發(fā)生的變化。 4、規(guī)劃網(wǎng)絡容量原則 在規(guī)劃@6A 站點的容量需求時，需要遵循下列原則： （1）通過開展市場分析（如果站點還沒有發(fā)布）或分析WEB服務器的日志（如果站點已經(jīng)在運行）確定同時用戶數(shù)量。 （2）使用高峰通信量來確定最大同時用戶數(shù)量。 （3）根據(jù)高峰同時用戶數(shù)量來計算硬件和網(wǎng)絡帶寬。處理器功率和RAM必須充足，以避免高峰使用時間性能降低。存儲應當非常充足，能保證@6: 站點所需的性能和可用性。 （4）站點拓樸結構必須考慮到服務器操作，如備份和復制、預期使用尖峰時段期間的性能、可用性需求，以及預期的未來增長。 （5）實施站點之前對其進行測試。 （6）將站點升級或擴展。擴展通常會大大提高性能，而且可提供更高的操作靈活性。 適應不斷的需求變更。 下面，本文以一個簡單的小例子來說明如何在軟件開發(fā)中應用敏捷建模。 投資方在他需要的財務管理系統(tǒng)中，對商品采購入庫的核算有如下要求：根據(jù)進項稅發(fā)票調(diào)用業(yè)務系統(tǒng)數(shù)據(jù)，由系統(tǒng)自動制作會計憑證。于是，開發(fā)人員就可以用非常簡潔的模型來表達這個需求然后，開發(fā)設計人員根據(jù)該圖完成該需求的開發(fā)工作。很顯然，這個功能很容易就被實現(xiàn)了。這就是第一次迭代過程。然后當演示給投資方時，他們的反饋如下： 由于公司的發(fā)展壯大，業(yè)務量增加很快，而且進口商品的采購也已經(jīng)成為經(jīng)常性業(yè)務，因此有如下要求： 1.在財務中，商品采購分為國內(nèi)商品采購和進口商品采購分別核算； 2.在進口采購中，記帳的依據(jù)是進口發(fā)票和稅單，而且記帳科目是物資采購； 3.國內(nèi)采購中，記帳科目是庫存商品。 根據(jù)這些反饋，設計人員對上述功能進行了調(diào)整，首先，必須將原商品采購模塊一分為二———進口采購和國內(nèi)采購，原模塊可以擴充為國內(nèi)采購模塊，進口采購模塊則需要重新開發(fā)。于是，很快就完成設計 應該說，到目前為止，變化的需求已大部分被修改并實施到軟件中了。此時已經(jīng)經(jīng)歷了兩次迭代。然后又可以把開發(fā)完成的軟件拿到客戶那里去演示了，也許客戶又有了新的要求，比如說，為避免業(yè)務上的數(shù)據(jù)有問題，應該允許財務人員手工錄入核算信息，于是開始了第三次迭代過程。依次類推，也就實踐了敏捷建模的迭代思想。 當然，本人并不認為要完全遵照敏捷建模的方法去完成需求管理，我們必須結合軟件工程中需求管理的方法和流程，將敏捷建模的思想融入在需求管理過程之中。 雖然，需求管理到目前為止尚無定法，但是只要我們在實踐中不斷探索，不斷總結，就一定能不斷的完善需求管理。