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