【文章內(nèi)容簡介】 39。39。 )39。 0 29 0 0 52 20001205 11:07: MSIB 項目組的第一項查詢優(yōu)化措施就是在追蹤分析過程中發(fā)現(xiàn)的。 MSIB 項目組在頁面上查找重復(fù)的查詢并減少冗余的 Select 語句。 MSIB 項目組很好地跟蹤了目標(biāo)的信息并對代碼重新排序，使得查詢操作只能進行由條件調(diào)用，從而完成了這一步驟。接下來， MSIB 項目組從磁盤讀取的角度確定了最為昂貴的查詢。 為了簡化這些操作，MSIB 項目組嘗試著降低查詢操作的 I/O 復(fù)雜性。 例如，改變 Select * 語句，使其歸入隔離更好的返回子集中。最后，MSIB 項目組通過 SQL 服務(wù)器調(diào)節(jié)向?qū)е胤帕擞涗浵碌母櫧Y(jié)果。 該向?qū)Ыㄗh對表格索引進行一些變更。 所有這些頁面級變更的組合降低了后端 SQL 服務(wù)器的負荷并因此改善了 MSIB Web 站點的可擴展性。在 SQL Server 服務(wù)器上，MSIB 項目組保留了與性能有關(guān)的所有默認配置。使用高速緩存方案提高吞吐量的下一步就是利用應(yīng)用服務(wù)器中的高速緩存。 MSIB 項目組利用了以下的高速緩存方案以優(yōu)化 MSIB 站點的性能。頁面輸出高速緩存Microsoft .NET Framework 系統(tǒng)內(nèi)內(nèi)置了頁面輸出高速緩存。 關(guān)于 MSIB 項目組如何使用這種功能的詳細情況在 MSIB Developers Guide 中有所介紹，該資料隨 MSIB 提供。 這種高速緩存方案對于未經(jīng)個性化的頁面是有效的，例如那些未用個性化內(nèi)容對象（PCO）顯示 Microsoft Content Management Server （MCMS）的頁面。MCMS 服務(wù)器的性能Microsoft Content Management Server (MCMS) 2002 可以在縱橫兩個方向上進行擴展。 目前正在編寫一份關(guān)于 MCMS 部署的文件，其中討論了各種可用于 MCMS 的高速緩存方法。 在編寫完成之后，可以從以下地址得到該文件 。如需了解關(guān)于 MCMS 2002 高速緩存的更多信息，參見 MCMS 2002 Help 中的“Optimizing MCMS Site Performance”。 如需了解關(guān)于利用 MCMS 2002 SCA 設(shè)置高速緩存屬性的更多信息，參見 MCMS 2002 Help 中的“Specifying cache properties”部分。 如需了解 MCMS 性能的更多信息，參見 MCMS 主頁，地址在 調(diào)節(jié)硬件在進行性能分析的過程中，為 Web 服務(wù)器和 SQL 服務(wù)器選擇正確的硬件發(fā)揮著非常重要的作用。 此外知道如何為這些服務(wù)器選擇正確的硬件還能夠讓您為其他用戶提供相關(guān)硬件的建議。 這一部分介紹了 MSIB 項目組是如何為本文所述的測試選擇 SQL 服務(wù)器的。Web 服務(wù)器在為 Web 服務(wù)器選擇硬件的時候， MSIB 項目組考慮了以下幾個方面：內(nèi)存磁盤子系統(tǒng)網(wǎng)絡(luò)系統(tǒng)CPU內(nèi)存MSIB 項目組為 Web 服務(wù)器配置了較大的隨機存取存儲器（RAM），所配容量超出了服務(wù)器運行任務(wù)所需的量。 為了確定服務(wù)器可以減少多少物理 RAM 內(nèi)存，之后項目組計算了在工作負載下服務(wù)器的最大工作集。 一個典型部署所需的 RAM 數(shù)量取決于您為該部署對高速緩存和內(nèi)存的需求。 不過，在大多數(shù)情況下，1GB 的物理 RAM 已經(jīng)是足夠的了。磁盤子系統(tǒng)MSIB 站點前端 Web 服務(wù)器的磁盤子系統(tǒng)作為一個只讀設(shè)備，是用來存儲自舉分區(qū)和站點內(nèi)容的。 這一子系統(tǒng)必需要有讀/寫設(shè)備才能進行文件分頁操作，不過如果有足夠的物理存儲器支持系統(tǒng)的話，這些操作都是最低限度的要求了。 Web 服務(wù)器確實是利用磁盤子系統(tǒng)寫事件日志和 Web 日志的。 這種操作已經(jīng)由 Windows 2000 操作系統(tǒng)進行了很好的調(diào)節(jié)，很少需要超過一個內(nèi)存芯片才能達到所需性能的。網(wǎng)絡(luò)系統(tǒng)Web 服務(wù)器上的網(wǎng)絡(luò)系統(tǒng)至少應(yīng)當(dāng)包括一塊 100BaseT 的網(wǎng)卡。 要實現(xiàn)更高的安全性、可管理性和可用性，服務(wù)器應(yīng)該配備兩塊甚至三塊網(wǎng)卡。 在 MSIB 項目組的測試中，web 服務(wù)器的網(wǎng)路吞吐量并不足以用完一塊 100 兆位的網(wǎng)卡能力。CPU最后，應(yīng)當(dāng)為服務(wù)器選用當(dāng)前最好的 CPU 和處理子系統(tǒng)。 在可以預(yù)見到的將來，這個特別的硬件子系統(tǒng)仍將是該服務(wù)器的瓶頸。 這是因為動態(tài) Web 頁動態(tài)和過程全面的性質(zhì)造成的。確定適當(dāng)?shù)?CPU 數(shù)量是 Microsoft Server 每處理器許可計劃的一項要求。 要確定這一需求，需要對您的 MSIB 站點進行一次 TCA 分析，在本文前面的“使用 TCA 方法進行容量規(guī)劃”一部分對此做了介紹。SQL 服務(wù)器MSIB 項目組利用本部分介紹的指南建立起了 SQL 服務(wù)器，使之并未成為 MSIB 部署中的瓶頸。在為 SQL 服務(wù)器選擇硬件的時候， MSIB 項目組考慮了以下幾個方面：內(nèi)存磁盤子系統(tǒng)數(shù)據(jù)庫內(nèi)存大量的隨機存取存儲器（RAM）對于 SQL 服務(wù)器是有好處的，因此您應(yīng)當(dāng)依照數(shù)據(jù)庫的工作集權(quán)衡 RAM 的數(shù)量。 在運行的時候測試網(wǎng)絡(luò)的輸入/輸出 （I/O）。 SQL 服務(wù)器的處理負荷將是訪問 SQL 服務(wù)器數(shù)據(jù)庫的前端服務(wù)器數(shù)量以及負荷配置文件的正函數(shù)。磁盤子系統(tǒng)一般情況下， SQL 服務(wù)器最重要的調(diào)節(jié)選項就是安裝物理磁盤子系統(tǒng)。 為了獲得最佳性能，數(shù)據(jù)庫應(yīng)當(dāng)與它們在不同物理驅(qū)動器上的業(yè)務(wù)處理記錄分離開來。 您應(yīng)當(dāng)建立起所有的數(shù)據(jù)庫、業(yè)務(wù)處理記錄和 TempDB ，這樣才不致讓單個的磁盤子系統(tǒng)成為瓶頸。 在 MSIB 項目組的測試方案中，磁盤子系統(tǒng)并未成為一個問題。 不過，對于正在運行中的站點來說，您應(yīng)當(dāng)認真地將磁盤成本和交易聯(lián)系起來考慮，以便為增加的磁盤需求做好規(guī)劃。數(shù)據(jù)庫MSIB 的設(shè)計使其可以進行橫向擴展并為后端數(shù)據(jù)庫系統(tǒng)分區(qū)。 用于營銷、用戶配置文件管理、目錄、數(shù)據(jù)倉庫、交易、內(nèi)容和管理的數(shù)據(jù)庫可以分離開來，放到物理 SQL 服務(wù)器數(shù)據(jù)庫中。 這樣一來您就能夠輕松地按照數(shù)據(jù)庫將部署系統(tǒng)分配到獨立的服務(wù)器或群集上去。 關(guān)于如何做到這一點的詳細介紹在隨 MSIB 附帶的 MSIB 部署指南中可以找到。調(diào)節(jié) IIS為了進行本分析，MSIB 項目組對前端 web 服務(wù)器進行了最小限度的調(diào)節(jié)。 在默認 Web 站點的 Properties 頁面的 Performance 選項卡上，性能調(diào)節(jié)塊被改變?yōu)槊刻斐^ 100000 次命中的數(shù)值。 所有其他的設(shè)置都保持原狀。 如果您必需要在測試站點或?qū)嶋H站點中改變?nèi)魏螀?shù)的話，那么請每次只改變一個，然后將新的結(jié)果與舊結(jié)果加以比較。重要事項： 對這些參數(shù)中的任何一個進行不適當(dāng)?shù)母淖兛赡軙o站點管理帶來麻煩。Web 群：MSIB 站點的擴展如果所需的 CPU P4EM 比單臺服務(wù)器所能提供的能力大，那么 Web 群將需要用到多臺 Web 服務(wù)器。 出于可用性和可靠性的考慮，MSIB 項目組建議在任何部署中最少都要使用兩臺 Web 服務(wù)器。類似地，如果現(xiàn)有的計算機出現(xiàn)了硬件資源的瓶頸，那么您應(yīng)當(dāng)為 Web 群添加后端 SQL 服務(wù)器。 在添加了更多 SQL 服務(wù)器之后，構(gòu)成 MSIB 解決方案的數(shù)據(jù)庫應(yīng)當(dāng)在 SQL 服務(wù)器中分離開來。第三部分 — MSIB 站點的可用性可用性規(guī)劃和可擴展性規(guī)劃是非常類似的兩項工作。 可用性規(guī)劃的第一步就是要確定您的業(yè)務(wù)需求。 作為一項指導(dǎo)，建議您重新審查一下您現(xiàn)有站點的行為，然后將您的站點與競爭對手們的站點加以比較。 如需獲得各個競爭對手的可用性和頁面等待時間等信息的列表，參見 ，地址在 。有兩個站點提供了全面的 Internet 性能和一般性能指導(dǎo)性原則， ，地址在 “”，地址在 。您可以按照不同級別的可用性部署 MSIB 解決方案。 應(yīng)當(dāng)在規(guī)劃階段中確定您的 MSIB 站點的可用性目標(biāo)。這一部分介紹了可用性，概述了可能會造成您的 MSIB 站點不可用的事件，提供了高可用性技術(shù)和建議，介紹了如何避免單點故障，并討論了 MSIB 企業(yè)部署的恢復(fù)模型。本部分包括：什么是可用性？使站點不可用的三類事件高可用性技術(shù)和建議避免單點故障MSIB 企業(yè)部署的恢復(fù)模型確定預(yù)期的可用性什么是可用性？本文中使用了可用性的定義，因為它是 Internet 站點涉及到的一個概念。 可用性包括可靠性、故障恢復(fù)和故障幾個方面。 最常用的可用性計量標(biāo)準(zhǔn)之一就是“九的個數(shù)”?！斑@一數(shù)字可以轉(zhuǎn)換為某一系統(tǒng)可正常工作的時間百分比。 例如，一個運行時間百分比為 的系統(tǒng)可以說成其可用性為五個九。 下表給出了九的個數(shù)和時間之間的對應(yīng)關(guān)系?？山邮艿倪\行時間百分比每天的停機時間每月的停機時間每年的停機時間95 分鐘36 小時 天99 分鐘7 小時 天 秒鐘43 分鐘 小時 秒鐘4 分鐘 分鐘 秒鐘26 秒鐘 分鐘從運行時間的角度來看可用性從上表可以看出，可接受運行時間為百分之 的系統(tǒng)平均每天只有 秒鐘或每月只有 43 分鐘是不可運行的。 要獲得更多個九的可用性，必需要對系統(tǒng)部署、軟件和解決方案實施的管理加以改進。 要預(yù)測一個系統(tǒng)何時甚至是隔多久會發(fā)生故障是非常困難的，因此要獲得更好的可靠性，一個關(guān)鍵的規(guī)劃方法是要縮短故障的恢復(fù)時間。 如果您的系統(tǒng)可以在 秒鐘之內(nèi)從故障中恢復(fù)過來，那么系統(tǒng)即使每天發(fā)生一次故障，仍然能夠達到三個九的可用性。從成功交易角度來看可用性上述的可用性概念是作為運行時間的函數(shù)分析的，與此相反是將可用性作為成功交易的函數(shù)來分析可用性這個概念。 換句話說，如果某一個 Web 站點每天處理 100000 個請求，那么百分之 的可用性就意味著每天有 100 個請求是失敗的。 如果您將此作為衡量可用性的標(biāo)準(zhǔn)，那么在業(yè)務(wù)規(guī)劃中對可用性的要求就可能會發(fā)生變化。 例如，在一天之內(nèi)一個 Web 站點的通信量是在改變的。 在凌晨兩點的時候，您的站點每小時的訪問次數(shù)可能還不到 100 。 如果您的站點在這期間發(fā)生故障，那么此時發(fā)生的失敗請求數(shù)量大約要比下午 5 點時少四倍，那個時候是一天中的峰值時刻，每小時的訪問次數(shù)為 400 次或更多。使站點不可用的三類事件有三類時間可能會造成您的 MSIB 站點無法工作，從而造成其不可用：人為錯誤、硬件故障和軟件故障。如果規(guī)劃不當(dāng)?shù)脑?，這些事件中的任何一個都可能會使站點的目標(biāo)可用性無法實現(xiàn)。人為錯誤人為錯誤是最需要認真對待的一類事件。 在用戶和正在工作的站點交互作用的時候，他們可能會執(zhí)行某些對站點管理造成不良影響的操作。 因此，強烈建議對管理操作首先在專門測試環(huán)境中加以測試然后再編寫腳本。 當(dāng)新的管理操作第一次用于實際運行站點的時候，應(yīng)當(dāng)對其進行仔細監(jiān)控，觀察其對整個系統(tǒng)的影響。 認真的規(guī)劃會有助于站點實現(xiàn)最高的可用性。 參見 MSIB Solutions Operations Guide 地址在 ，其中介紹了可以減少人為錯誤的主意和最佳做法。硬件故障硬件故障可能會在任何時候發(fā)生。 這類故障包括環(huán)境故障，如天災(zāi)和火災(zāi)等。 在硬件實現(xiàn)的設(shè)計中將單點故障降到最低是降低這種風(fēng)險的最安全方式。 在部署計劃階段中，MSIB 站點的實施人員應(yīng)當(dāng)編制一份硬件地圖，給出存儲器、網(wǎng)絡(luò)和軟件邏輯的所有連接點。 之后可以制定解決潛在單點故障的方案并進行成本和風(fēng)險對比分析。 這方面可以有很多不同的解決方案，從自始至終對關(guān)鍵數(shù)據(jù)進行簡單磁帶備份到可以容災(zāi)的系統(tǒng)防護系統(tǒng)不一而足。軟件故障軟件故障是可能導(dǎo)致您的站點無法工作的第三類事件。 為了避免因軟件故障造成總的功能損失，MSIB 使用了群集技術(shù)以提高可用性。 站點代碼和基本部件的設(shè)計允許在發(fā)生臨時故障的時候進行重試操作。 MSIB 解決方案中執(zhí)行交易的部分利用了 Distributed Transaction Coordinator (DTC)、Microsoft Message Queue (MSMQ) 和交易以保證數(shù)據(jù)的完整性。高可用性技術(shù)和建議這一部分介紹了一些技術(shù)和建議，幫助您部署一個高可用性的 MSIB 站點。本部分包括：用于高可用性的群集和負載均衡技術(shù)旨在獲得高可用性的軟件建議旨在獲得高可用性的硬件建議用于高可用性的群集和負載均衡技術(shù)群集是指一組相互獨立的計算機，它們共同合作運行公共的一套應(yīng)用程序或服務(wù)，對客戶端和應(yīng)用程序來說像是單個系統(tǒng)一樣。 群集計算機在物理上通過網(wǎng)線連接到一起，在程序上則通過群集軟件連接到一起。 這些連接使得這些計算機可以使用單獨的計算機無法使用的一些問題解決功能，例如負載均衡和故障切換等。負載均衡功能將負載在所有配置的服務(wù)器之間分配，防止某一臺服務(wù)器負載過度。 通過這種方式從而又讓您能夠逐步增大容量以滿足自己的需求。 故障切換功能可以自動將資源從故障的或脫機的群集服務(wù)器上轉(zhuǎn)移到正在運行的一臺服務(wù)器上，從而為用戶提供了恒定的支持。 這樣用戶就始終都可以訪問 MSIB 站點的資源了。 目前，Windows Clustering 可以提供如下的群集和負載均衡技術(shù)：網(wǎng)絡(luò)負載均衡Microsoft 群集服務(wù)組件負載均衡網(wǎng)絡(luò)負載均衡網(wǎng)絡(luò)負載均衡（NLB）技術(shù)可以把多達 32 臺運行 Windows 2000 Advanced Server 組合到經(jīng)負載均衡的單個群集中，從而可以提供基于 TCP/IP 的應(yīng)用和服務(wù)的可擴展性和高可用性。在本文測試的 MSIB 企業(yè)部署中，MSIB 項目組利用 NLB 技術(shù)將下表所列的服務(wù)器群集了起來。服務(wù)器備注前端 Web 服務(wù)器( IIS 和商務(wù)服務(wù)器 )可以利用 MSIB 解決方案對前端 web 服務(wù)器進行負載均衡的原因在于 Web 服務(wù)器中沒有維護每個用戶的狀態(tài)信息。 所有的相關(guān)數(shù)據(jù)都是通過 Commerce Server 2002 的對象返回到 SQL 服務(wù)器的。搜索服務(wù)器（帶搜索組件的 SharePoint 門戶服務(wù)器）由于 Internet 上所有的通信量都是發(fā)自客戶的，MSIB 項目組利用 NLB 配置了這些內(nèi)容以便在峰值使用時段提