簡(jiǎn)介

Microsoft? SQL Server? Reporting Services 是一個(gè)將集中管理的報(bào)告服務(wù)器具有的伸縮性和易管理性與基于 Web 和桌面的報(bào)告交付手段集于一身的報(bào)告平臺(tái)。Reporting Services 是微軟功能全面的商業(yè)智能平臺(tái)的重要組件。

對(duì)于許多組織，通過(guò)報(bào)告提供信息是日常業(yè)務(wù)操作的一種基本活動(dòng)。所以，報(bào)告系統(tǒng)的性能表現(xiàn)必須確保一致和可預(yù)測(cè)。隨著報(bào)告負(fù)載的增加，組織必須能夠以一種可預(yù)期和具有成本效益的方式提高報(bào)告能力。

關(guān)于本文

本文旨在幫助客戶和合作伙伴確定如何面對(duì)日益增加的負(fù)載，以最佳方式規(guī)劃、優(yōu)化和伸縮他們的報(bào)告服務(wù)實(shí)現(xiàn)架構(gòu)。本白皮書(shū)討論了以下主題：

?	不同硬件配置的性能表現(xiàn)和伸縮特性（如縱向伸縮和橫向伸縮）
?	報(bào)告緩存和文件系統(tǒng)存儲(chǔ)對(duì)性能的影響
?	有關(guān) Reporting Services 性能優(yōu)化的最佳做法
?	有關(guān)運(yùn)行您自己的性能測(cè)試的建議

雖然本白皮書(shū)關(guān)注的目標(biāo)是 Microsoft SQL Server 2005 Reporting Services，但文中提供的大多數(shù)信息也適用于該產(chǎn)品的早期版本。

前提條件

本白皮書(shū)并不打算事無(wú)巨細(xì)地包含有關(guān) Reporting Services 的所有信息。如需獲得有關(guān)該產(chǎn)品的詳細(xì)信息，請(qǐng)參見(jiàn)產(chǎn)品文檔以及可通過(guò)以下地址獲得的其他在線資源：http://www.microsoft.com/sql/reporting/.

除 Reporting Services 之外，本文檔假設(shè)讀者已經(jīng)熟悉以下主題：

?	Microsoft SQL Server
?	Internet Information Services (IIS)
?	Microsoft .NET Framework

有關(guān)這些主題的信息可通過(guò)以下地址從 MSDN 網(wǎng)站上獲得：http://msdn.microsoft.com?

返回頁(yè)首

概述

Reporting Services 是基于服務(wù)器的全面平臺(tái)，用于創(chuàng)建、管理和交付基于紙張的傳統(tǒng)報(bào)告和基于 Web 的互動(dòng)式報(bào)告。在執(zhí)行報(bào)告時(shí)，Reporting Services 執(zhí)行以下基本工作：

?	取得要報(bào)告的數(shù)據(jù)
?	根據(jù)報(bào)告定義中的指令處理數(shù)據(jù)
?	以特定格式呈現(xiàn)報(bào)告

Reporting Services 還執(zhí)行支持報(bào)告處理的其他工作，例如管理和處理訂閱，管理和處理快照和緩存請(qǐng)求，以及提交報(bào)告管理請(qǐng)求。

Reporting Services 的工作負(fù)載主要來(lái)自于以下三種應(yīng)用情境：

?	在線用戶對(duì)已發(fā)布報(bào)告的互動(dòng)式訪問(wèn)
?	根據(jù)預(yù)先計(jì)劃或由事件驅(qū)動(dòng)，通過(guò)訂閱以電子郵件或文件共享方式交付報(bào)告
?	由在線用戶動(dòng)態(tài)創(chuàng)建和執(zhí)行的特別報(bào)告

本白皮書(shū)集中討論第一種應(yīng)用情境，即由在線用戶執(zhí)行已發(fā)布報(bào)告。這是大多數(shù)客戶希望增強(qiáng)其伸縮能力的主要工作負(fù)載。

交 付訂閱報(bào)告的優(yōu)點(diǎn)在于可以預(yù)先設(shè)定日程安排，因此為您賦予了控制在何時(shí)和何處執(zhí)行處理過(guò)程的更強(qiáng)能力。互動(dòng)式報(bào)告則更難于做出規(guī)劃，因?yàn)樗艽蟪潭壬弦?決于報(bào)告的規(guī)模和復(fù)雜性、并發(fā)用戶的數(shù)量以及報(bào)告的呈現(xiàn)格式。在訪問(wèn)互動(dòng)式報(bào)告時(shí)，用戶還對(duì)系統(tǒng)響應(yīng)速度抱有很高的期望。

利用 SQL Server 2005 Reporting Services，最終用戶可使用新的 Report Builder 工具，以交互方式創(chuàng)建和執(zhí)行報(bào)告。創(chuàng)建特別報(bào)告為 Report Server 帶來(lái)的額外負(fù)擔(dān)很難進(jìn)行量化，因?yàn)檫@要視用戶操作的內(nèi)容及效率而定。特別報(bào)告的伸縮性將在本白皮書(shū)今后的版本中予以介紹。

本白皮書(shū)包含一些通用的性能指南，這些指南是微軟在針對(duì)不同配置創(chuàng)建和測(cè)試交互式報(bào)告負(fù)載的過(guò)程中總結(jié)而成的。但是，若要獲得能夠反映您自身環(huán)境的具體性能數(shù)字，需要您自己運(yùn)行性能測(cè)試。本白皮書(shū)所提供圖形和結(jié)果的目的僅是幫助用戶了解不同配置具有的伸縮特性。

伸縮性和可靠性

系統(tǒng)伸縮性難以定義，因?yàn)樗?jīng)常對(duì)不同的人具有不同的含義。之所以如此，是因?yàn)槿藗兘?jīng)常將伸縮性與可靠性放在一起進(jìn)行討論。雖然可靠性是任何系統(tǒng)配置都不可忽視的重要考慮事項(xiàng)，但是它的存在是否會(huì)對(duì)實(shí)際的伸縮性造成影響并無(wú)法確定。

在 本文中，伸縮性被定義為：在不從根本上改變系統(tǒng)設(shè)計(jì)或架構(gòu)的情況下，通過(guò)逐步增加系統(tǒng)資源讓系統(tǒng)支持更多工作負(fù)載的一種能力。理想情況下，隨著系統(tǒng)資源的 增加，系統(tǒng)處理工作負(fù)載的能力也應(yīng)隨之成比例增加。雖然這聽(tīng)起來(lái)很直觀，但是實(shí)現(xiàn)?°近乎線性?±的伸縮性通常十分困難。實(shí)際上，系統(tǒng)通常無(wú)法實(shí)現(xiàn)完美的 線性伸縮。這是由于部署在各種異類(lèi)系統(tǒng)中的多個(gè)應(yīng)用程序組件間必不可少的管理、協(xié)調(diào)和溝通工作會(huì)帶來(lái)的大量的開(kāi)銷(xiāo)。

系統(tǒng)可靠性所基于的觀點(diǎn) 則與此稍有不同。可靠系統(tǒng)是一種在不出現(xiàn)故障的情況下對(duì)不斷增加的工作負(fù)載進(jìn)行妥善處理的系統(tǒng)。此外，可靠系統(tǒng)不應(yīng)隨著工作負(fù)載的增加而出現(xiàn)崩潰或運(yùn)行中 止。相反，其性能只應(yīng)出現(xiàn)緩慢的下降。但是，在壓力足夠大的情況下，任何系統(tǒng)都可能變得不可用。而可靠系統(tǒng)的獨(dú)特之處就在于它們能夠從這些事件中恢復(fù)。

對(duì)于為實(shí)施 Reporting Services 而進(jìn)行的容量規(guī)劃，其成功關(guān)鍵便在于在工作過(guò)載和系統(tǒng)平滑處理增加的工作負(fù)載之間找到平衡，并籍此建立滿足伸縮性要求的可靠系統(tǒng)。

縱向伸縮和橫向伸縮

Reporting Services 的靈活設(shè)計(jì)使得用戶既可在單臺(tái)服務(wù)器也可在多臺(tái)服務(wù)器上部署其組件，具體情況則取決于用戶的需要和喜好。

開(kāi)始時(shí)，Reporting Services 的用戶經(jīng)常詢問(wèn)應(yīng)購(gòu)買(mǎi)單臺(tái)的大型服務(wù)器（縱向伸縮）還是應(yīng)購(gòu)買(mǎi)多臺(tái)小型服務(wù)器（橫向伸縮）。本白皮書(shū)介紹了 Reporting Services 的伸縮特性，在解答用戶提出的這個(gè)問(wèn)題的同時(shí)幫助他們做出明智決策。

縱向伸縮途徑使用一臺(tái)大型的對(duì)稱(chēng)多處理器服務(wù)器提供更高的處理能力。與橫向伸縮相比，這種方法的優(yōu)點(diǎn)在于它具有更為輕松的配置和管理體驗(yàn)?？v向伸縮還是一種用于伸縮 SQL Server 關(guān)系型引擎和 Analysis Services 的方法。

橫向伸縮是 Reporting Services Enterprise Edition 支持的配置方式，也是大多數(shù)客戶考慮采用的伸縮方式。這主要是由于橫向伸縮：

?	允許用戶根據(jù)需要逐步增加或撤除容量
?	為增加和撤除容量提供了一種非常靈活、易于管理和價(jià)格可承受的方法。
?	允許在多臺(tái)商用服務(wù)器上平衡大量工作負(fù)載
?	提供了一定程度的固有容錯(cuò)能力

如 果您決定使用橫向伸縮配置方式部署 Reporting Services，應(yīng)當(dāng)意識(shí)到需要在多臺(tái) Report Servers 之間進(jìn)行協(xié)調(diào)，讓它們都能夠訪問(wèn)安裝在本地或遠(yuǎn)程 SQL Server 關(guān)系型數(shù)據(jù)庫(kù)上的單個(gè) Report Server 目錄。有關(guān) Reporting Services 部署選項(xiàng)的更多信息，請(qǐng)參閱位于如下地址的在線文檔：http://www.microsoft.com/sql/reporting/ 和 http://technet.microsoft.com/sql.

Reporting Services 組件

為了全面理解伸縮性，首先需要理解 Reporting Services 的體系結(jié)構(gòu)（如圖 1 所示）和它的各個(gè)組件。

圖 1：Reporting Services 的體系結(jié)構(gòu)
查看大圖

Reporting Services 從邏輯上可劃分為三層（如表 1 所示）。

表 1

組件	功能
Report Server	一個(gè)具備如下功能的 Web 服務(wù)： ? 處理 SOAP (Simple Object Access Protocol) 和 URL 請(qǐng)求 ? 處理報(bào)告，包括執(zhí)行查詢，計(jì)算表達(dá)式和生成輸出格式 ? 提供快照和報(bào)告緩存管理 ? 支持并應(yīng)用安全策略和授權(quán) Report Server 還包括一個(gè)負(fù)責(zé)日程計(jì)劃和批操作的 Windows 服務(wù)。本白皮書(shū)未討論該應(yīng)用情境的伸縮性問(wèn)題。
Report Server Catalog	以下兩個(gè) SQL Server 數(shù)據(jù)庫(kù)來(lái)自該目錄： ? ReportServer 包含內(nèi)容信息，包括報(bào)告定義、報(bào)告元數(shù)據(jù)、數(shù)據(jù)源定義、快照以及歷史。它存儲(chǔ)安全設(shè)置、帳戶信息、日程安排以及交付設(shè)置。 ? ReportServerTempDB 保存支持會(huì)話管理所需的內(nèi)容并且緩存報(bào)告數(shù)據(jù)。 該目錄可與 Report Server 駐留在同一物理系統(tǒng)上，也可位于不同系統(tǒng)上（遠(yuǎn)程目錄）。
客戶端應(yīng)用程序	客 戶端應(yīng)用程序通過(guò) SOAP Web 服務(wù)和 URL 請(qǐng)求訪問(wèn)服務(wù)器。Report Management 工具和 Report Viewer 應(yīng)用程序是包含在 Reporting Services 之中的客戶端應(yīng)用程序。Microsoft? Visual Studio? 2005 為在客戶端系統(tǒng)中嵌入報(bào)告提供了 Report Viewer。Report Builder 是用于特別報(bào)告的報(bào)告制作工具。許多第三方軟件廠商還提供它們自己的客戶端應(yīng)用程序。

返回頁(yè)首

伸縮指南

本部分內(nèi)容介紹 Reporting Services 的基本配置選項(xiàng)，并描述它們對(duì)性能和伸縮性的影響。本部分內(nèi)容的目標(biāo)是幫助讀者找出滿足自身的性能和負(fù)載需要的有效 Reporting Services 配置，并且回答如下問(wèn)題：

?	您應(yīng)該考慮在遠(yuǎn)程計(jì)算機(jī)上承載目錄嗎？
?	對(duì) Report Server 進(jìn)行縱向伸縮和增添其他 Report Server 這兩種方法哪一種更佳？
?	對(duì)于配備四顆處理器的 Report Server，哪一種配置方式最佳？

雖然微軟對(duì)不同配置執(zhí)行的測(cè)試均在施加特定報(bào)告負(fù)載的情況下得出了結(jié)果，但您的實(shí)際性能需求應(yīng)視您的自身環(huán)境所特有的各項(xiàng)因素而定。這些因素包括：

?	并發(fā)用戶的數(shù)量
?	所產(chǎn)生報(bào)告的大小和復(fù)雜性
?	按需生成報(bào)告還是通過(guò)訂閱生成報(bào)告
?	實(shí)時(shí)生成報(bào)告還是緩存報(bào)告

后文中的測(cè)試結(jié)果僅用于確定各種不同配置的相對(duì)性能和伸縮特性。請(qǐng)注意，原始指標(biāo)（例如每秒的頁(yè)面瀏覽量）與您的環(huán)境和應(yīng)用情境不同。我們的重點(diǎn)在于這些指標(biāo)隨著向環(huán)境分配或增添資源而取得的相對(duì)改善。本白皮書(shū)后面的章節(jié)為您創(chuàng)建自己的性能基準(zhǔn)提供了操作指南。

本地配置和遠(yuǎn)程配置

微軟測(cè)試了兩種本地配置，在同一臺(tái)服務(wù)器上運(yùn)行 Report Server 及其目錄。

查看大圖

在 本地配置方式中，SQL Server 關(guān)系型數(shù)據(jù)庫(kù)將與 Report Server 爭(zhēng)奪可用的計(jì)算機(jī)資源。如果有足夠的資源，將不會(huì)出現(xiàn)任何問(wèn)題。您可能應(yīng)考慮將最大數(shù)量的內(nèi)存和最多數(shù)量的處理器設(shè)置為由 SQL Server 數(shù)據(jù)庫(kù)引擎使用，以減少它與 Reporting Services 間的資源爭(zhēng)用。有關(guān)更多信息，請(qǐng)參見(jiàn)附錄 A。用戶還可選擇圖 2 中展示的配置，因?yàn)樗鼉H需一份 SQL Server 許可證。

作為對(duì)比，圖 3 中展示的遠(yuǎn)程目錄實(shí)現(xiàn)方式需要將 Reporting Services 組件分布在兩臺(tái)物理服務(wù)器上。第一臺(tái)服務(wù)器承載 Report Server 引擎，而第二臺(tái)則以遠(yuǎn)程方式承載目錄。

圖 3：遠(yuǎn)程目錄實(shí)現(xiàn)方式
查看大圖

遠(yuǎn)程配置方式消除了 Report Server 和承載目錄的 SQL Server 之間對(duì)計(jì)算機(jī)資源的爭(zhēng)奪。但是，您必須在 Report Server 和目錄服務(wù)器間提供足夠的網(wǎng)絡(luò)帶寬。

縱向伸縮和橫向伸縮

在將目錄分隔到其他系統(tǒng)中后，可以選擇通過(guò)增加處理器來(lái)對(duì) Report Server 執(zhí)行縱向伸縮，也可以通過(guò)增加計(jì)算機(jī)來(lái)執(zhí)行橫向伸縮。圖 4 描述了使用多臺(tái) Report Server 訪問(wèn)單個(gè)目錄的橫向伸縮配置。

?

圖 4：使用多臺(tái) Report Server 訪問(wèn)單個(gè)目錄的橫向伸縮配置方式
查看大圖

通 常，橫向伸縮配置方式使用一臺(tái)遠(yuǎn)程關(guān)系型數(shù)據(jù)庫(kù)服務(wù)器，該服務(wù)器用于承載目錄，并且與所有 Report Server 節(jié)點(diǎn)均分開(kāi)布置。雖然可將目錄放在其中一個(gè) Report Server 節(jié)點(diǎn)上，但我們不推薦采用這種配置方式，因?yàn)閿?shù)據(jù)庫(kù)服務(wù)器將與 Report Server 爭(zhēng)奪資源。

4 顆處理器的橫向伸縮配置方式使用 2 臺(tái) Report Server（每臺(tái)服務(wù)器配備 2 顆處理器）訪問(wèn)遠(yuǎn)程目錄。8 處理器的橫向伸縮配置方式使用 4 臺(tái)配備 2 顆處理器的 Report Server。因此，橫向伸縮配置不僅處理器數(shù)量會(huì)成倍增加，而且內(nèi)存和網(wǎng)絡(luò)帶寬也同樣會(huì)成倍增加。

本地目錄和遠(yuǎn)程目錄性能比較

在伸縮性規(guī)劃中需要首先決定的事情之一便是：是在與 Report Server 相同的系統(tǒng)上承載 Report Server 目錄（本地模式），還是分開(kāi)單獨(dú)承載目錄（遠(yuǎn)程模式）。

在本地模式中，一臺(tái)物理計(jì)算機(jī)同時(shí)承載 Report Server 和 Report Server 目錄（一個(gè) SQL Server 實(shí)例）。該目錄獨(dú)立于報(bào)告數(shù)據(jù)的源數(shù)據(jù)庫(kù)，此數(shù)據(jù)庫(kù)通常位于其他服務(wù)器上。

單臺(tái)計(jì)算機(jī)的設(shè)置方式是最簡(jiǎn)單的實(shí)現(xiàn)方式，從許可證的觀點(diǎn)看，也是較為便宜的配置方式，但是它仍然具有幾個(gè)缺點(diǎn)。最重要的是，將目錄移動(dòng)到遠(yuǎn)程服務(wù)器是朝橫向伸縮配置方式邁出的第一步。本文的以后部分將對(duì)此進(jìn)行討論。

在回答向本地實(shí)現(xiàn)方式添加處理器和分離出目錄這兩種方式哪一種較佳這個(gè)問(wèn)題時(shí)，我們使用如下系統(tǒng)配置進(jìn)行了測(cè)試：

?	配備 2 顆處理器的 Report Server，本地目錄（2 處理器）
?	配備 2 顆處理器的 Report Server，遠(yuǎn)程目錄（遠(yuǎn)程 2 顆處理器）
?	配備 4 顆處理器的 Report Server, 本地目錄（4 處理器）
?	配備 4 顆處理器的 Report Server，遠(yuǎn)程目錄（遠(yuǎn)程 4 顆處理器）

測(cè)試結(jié)果揭示了幾個(gè)很有意思的事實(shí)，為究竟應(yīng)首先縱向伸縮處理器還是應(yīng)首先分隔報(bào)告目錄這個(gè)問(wèn)題提供了答案。

?	對(duì)于使用 2 顆處理器的系統(tǒng)，本地和遠(yuǎn)程實(shí)現(xiàn)方式在輕負(fù)載情況下的性能表現(xiàn)大致相同。
?	相比于 2 顆處理器的本地系統(tǒng)，4 顆處理器的本地系統(tǒng)在每秒處理的請(qǐng)求數(shù)這一指標(biāo)上具有較好的表現(xiàn)，但是并不像 4 顆處理器的遠(yuǎn)程系統(tǒng)那樣實(shí)現(xiàn)了性能翻番。

表 2 展示了四種配置方式的峰值處理能力（即性能保持在等于 30 秒的閥值之上時(shí)能夠處理的最大會(huì)話數(shù)量）的比較結(jié)果。

表 2

?	每秒的平均請(qǐng)求數(shù)	峰值會(huì)話數(shù)
2 處理器（本地）	基準(zhǔn)	基準(zhǔn)
2 處理器（遠(yuǎn)程）	-10%	基準(zhǔn)
4 處理器（本地）	53%	17%
4 處理器（遠(yuǎn)程）	100%	117%

從 2 處理器的本地實(shí)現(xiàn)方式切換到 2 處理器的遠(yuǎn)程實(shí)現(xiàn)方式本身對(duì)服務(wù)器能夠支持的峰值會(huì)話數(shù)量不會(huì)產(chǎn)生實(shí)質(zhì)性的影響。在吞吐量方面會(huì)有一點(diǎn)下降，因?yàn)橥ㄟ^(guò)網(wǎng)絡(luò)傳輸數(shù)據(jù)會(huì)產(chǎn)生一定的開(kāi)銷(xiāo)。

在更高工作負(fù)載的情況下，成倍增加本地目錄實(shí)現(xiàn)方式上的處理器數(shù)量（從 2 顆處理器的本地實(shí)現(xiàn)到 4 顆處理器的本地實(shí)現(xiàn)）實(shí)際并不能將可用資源提高兩倍。它只能適度提高峰值會(huì)話數(shù)量，并在每秒處理的請(qǐng)求數(shù)方面有 53% 的改進(jìn)。

但是，在遠(yuǎn)程目錄實(shí)現(xiàn)方式中，成倍增加處理器（從 2 顆到 4 顆）可提供線性的伸縮能力。在 4 顆處理器的情況下，峰值請(qǐng)求數(shù)量的成倍增加還有甚于峰值會(huì)話數(shù)量的成倍增加。

關(guān)鍵點(diǎn)

?	如果您正在運(yùn)行 2 顆處理器的本地系統(tǒng)，將目錄分隔到其他服務(wù)器上對(duì)系統(tǒng)整體性能帶來(lái)的提升最少。
?	分隔目錄會(huì)為管理和監(jiān)視這樣的工作帶來(lái)便利，因?yàn)橄到y(tǒng)不再需要在 Report Server 和數(shù)據(jù)庫(kù)進(jìn)程間分配資源。
?	如果您正在運(yùn)行 4 顆處理器的本地系統(tǒng)，將目錄分隔到其他服務(wù)器會(huì)顯著提升系統(tǒng)的性能。
?	對(duì)于打算提高伸縮性的系統(tǒng)，遠(yuǎn)程目錄實(shí)現(xiàn)方式是朝橫向伸縮配置方式邁出的第一步。

縱向伸縮

本 部分內(nèi)容討論在遠(yuǎn)程目錄配置方式中通過(guò)增加處理器數(shù)量（縱向伸縮）來(lái)提升系統(tǒng)的容量和性能。在本例中，縱向伸縮是從 2 顆處理器的遠(yuǎn)程系統(tǒng)切換為 4 顆處理器的遠(yuǎn)程系統(tǒng)。在以下測(cè)試中，當(dāng)響應(yīng)時(shí)間超過(guò)預(yù)先定義的 30 秒閥值之后便視為達(dá)到了極限，這個(gè)時(shí)間對(duì)于大多數(shù)用戶來(lái)說(shuō)似乎都是無(wú)法忍受的。

表 3

?	每秒的平均請(qǐng)求數(shù)	最大會(huì)話數(shù)量	每分鐘的頁(yè)面瀏覽量
2 處理器（遠(yuǎn)程）	10.71（基準(zhǔn)）	600（基準(zhǔn)）	604（基準(zhǔn)）
4 處理器（遠(yuǎn)程）	23.91 (123%)	1300 (117%)	1327 (120%)

每秒的平均請(qǐng)求數(shù)

在高用戶負(fù)載情況下，4 處理器系統(tǒng)每秒可以處理的請(qǐng)求數(shù)顯然遠(yuǎn)遠(yuǎn)大于 2 顆處理器的遠(yuǎn)程系統(tǒng)。在遠(yuǎn)程目錄實(shí)現(xiàn)方式中，成倍增加處理器的數(shù)量可以使得每秒的平均請(qǐng)求數(shù)稍稍高于原先的兩倍。

最大會(huì)話數(shù)量

4 處理器的遠(yuǎn)程配置方式可以支持的最大會(huì)話數(shù)量超過(guò)了 2 顆處理器的遠(yuǎn)程實(shí)現(xiàn)方式所支持最大會(huì)話數(shù)量的 2 倍。

每分鐘頁(yè)面瀏覽量

每分鐘頁(yè)面瀏覽量這一指標(biāo)考察了頁(yè)面生成能力。在遠(yuǎn)程目錄實(shí)現(xiàn)方式中，通過(guò)將處理器數(shù)量從 2 成倍增加到 4，可以在高負(fù)載情況下將頁(yè)面瀏覽量提升為原先的 120%。

關(guān)鍵點(diǎn)

?	在將報(bào)告目錄分隔到其他系統(tǒng)后，將處理器數(shù)量從 2 成倍增加到 4 基本上可將 Reporting Services 的處理能力成倍增加，同時(shí)不會(huì)降低系統(tǒng)的響應(yīng)速度。
?	僅針對(duì)將處理器數(shù)量從 2 增加到 4 的情況進(jìn)行了測(cè)試。以后的測(cè)試將考察使用更多處理器來(lái)優(yōu)化系統(tǒng)的情況。

橫向伸縮

本部分內(nèi)容考察橫向伸縮配置對(duì)容量和性能的影響。在微軟進(jìn)行的測(cè)試中，Report Servers 忠實(shí)地復(fù)制了 2 顆處理器遠(yuǎn)程目錄實(shí)現(xiàn)方式中的服務(wù)器配置。因此，橫向伸縮服務(wù)器的數(shù)量加倍，而所有系統(tǒng)資源（內(nèi)存、存儲(chǔ)和網(wǎng)卡）的數(shù)量則翻了四倍。

如果將 2 顆處理器的遠(yuǎn)程實(shí)現(xiàn)方式的系統(tǒng)處理能力與 4 顆或 8 顆處理器的橫向伸縮配置進(jìn)行對(duì)比，使用橫向伸縮配置的系統(tǒng)可以提供近乎線性的伸縮能力。下表總結(jié)了 4 顆和 8 顆處理器的橫向伸縮配置相對(duì)于作為基準(zhǔn)的 2 顆處理器遠(yuǎn)程系統(tǒng)在各方面取得的進(jìn)步。

表 4

?	峰值頁(yè)面瀏覽量/小時(shí)	最大并發(fā)會(huì)話數(shù) (11/14/2005)
2 處理器（遠(yuǎn)程）	10.71（基準(zhǔn)）	600（基準(zhǔn)）
2 X 2 處理器（遠(yuǎn)程）	23.87 (210%)	1300 (216%)
4 X 2 處理器（遠(yuǎn)程）	45.18 (378%)	2500 (416%)

比較每秒的峰值平均請(qǐng)求數(shù)以及支持的峰值會(huì)話數(shù)，2 X 2 處理器的橫向伸縮配置方式提供了優(yōu)于 2 顆處理器遠(yuǎn)程實(shí)現(xiàn)方式的線性伸縮能力。

如果僅比較各種橫向伸縮實(shí)現(xiàn)，從 2 X 2 處理器的橫向伸縮轉(zhuǎn)移到 4 X 2 處理器的橫向伸縮不會(huì)提供真正線性的伸縮能力。但是，它也可顯著提升處理能力，每秒處理的請(qǐng)求數(shù)增加了 89%，而支持的峰值會(huì)話數(shù)則提高了 92%。

關(guān)鍵點(diǎn)

?	橫向伸縮途徑是一條極具成本效益的途徑，可在無(wú)需大量硬件投入的情況下極大提升系統(tǒng)容量。
?	如果您預(yù)計(jì)對(duì) Reporting Services 的需求將持續(xù)增加，那么橫向伸縮是根據(jù)需要增加更多容量的一種靈活方法。

縱向伸縮和橫向伸縮比較

縱向伸縮和橫向伸縮應(yīng)用方案的直接比較可以通過(guò)比較 4 處理器的遠(yuǎn)程目錄和 4 處理器的橫向伸縮的容量來(lái)進(jìn)行。在第一種情況下，四顆處理器位于同一臺(tái) Report Server 上，而橫向伸縮則使用兩臺(tái)配備了 2 顆處理器的 Report Servers。

測(cè)試結(jié)果表明，兩種實(shí)現(xiàn)方式之間的差別有限，在每秒的平均請(qǐng)求數(shù)和支持的峰值會(huì)話數(shù)方面它們都旗鼓相當(dāng)。

橫向伸縮在所有節(jié)點(diǎn)上總共使用了 8 GB 內(nèi)存，而 4 處理器的遠(yuǎn)程系統(tǒng)則使用了 4 GB 內(nèi)存。

在 同樣會(huì)話數(shù)的情況下，4 處理器系統(tǒng)的系統(tǒng)響應(yīng)時(shí)間方面也不落下風(fēng)。4 處理器的橫向伸縮配置在響應(yīng)時(shí)間方面稍占優(yōu)勢(shì)。由于在 Reporting Services 部署中，我們對(duì) ASP.NET 應(yīng)用程序進(jìn)行了仔細(xì)調(diào)較以充分利用橫向伸縮配置中價(jià)格便宜的硬件設(shè)備，這個(gè)結(jié)果在我們的預(yù)料之中。

關(guān)鍵點(diǎn)

如 果您已經(jīng)擁有一個(gè) 2 處理器的遠(yuǎn)程目錄系統(tǒng)，并且必須將其處理能力翻番，將該系統(tǒng)縱向伸縮到 4 處理器的 Report Server 或橫向伸縮為兩臺(tái) Report Servers 都是可行的。雖然轉(zhuǎn)移到橫向伸縮配置要求您轉(zhuǎn)移到 Reporting Services Enterprise Edition，但在獲得能力提升之外還可獲得其他眾多益處。這些益處包括：

?	處理器數(shù)目較少的服務(wù)器價(jià)格與大型的 SMP 服務(wù)器相比較為低廉。
?	其他計(jì)算機(jī)可以利用專(zhuān)用的內(nèi)存地址空間，而無(wú)需轉(zhuǎn)移到 64 位系統(tǒng)。
?	利用增加服務(wù)器而不是升級(jí)現(xiàn)有服務(wù)器來(lái)提升能力的做法具有更短的停機(jī)時(shí)間。
?	使用多臺(tái)報(bào)告服務(wù)器的做法具有更出色的可用性，如果某臺(tái)服務(wù)器發(fā)生故障，整個(gè)系統(tǒng)仍然可以繼續(xù)響應(yīng)請(qǐng)求。
?	可以輕松地將橫向伸縮擴(kuò)展到 6、8 或 10 顆處理器。通常，在伸縮至 8 顆處理器后，SMP 服務(wù)器的性能增長(zhǎng)將后繼乏力。

使用 64 位處理器

SQL Server 2005 Reporting Services 支持 64 位處理器，包括 Intel Itanium2 處理器以及 AMD 和 Intel 的 x64 架構(gòu)。在 x64 系統(tǒng)上，Reporting Services 既可運(yùn)行于本機(jī) 64 位模式，也可以運(yùn)行于 32 位的 Windows on Windows (WOW) 子系統(tǒng)上。

通常，在具有相同速度的處理器上運(yùn)行 64 位系統(tǒng)不會(huì)提高報(bào)告的吞吐量。相反，從中獲得主要好處是用戶可以查看和導(dǎo)出大型報(bào)告的輸出結(jié)果。當(dāng)工作負(fù)載提高時(shí)，可以在 64 位計(jì)算機(jī)上獲得更大吞吐能力，因?yàn)閷?duì)內(nèi)存的爭(zhēng)用減少了，而且垃圾回收操作的頻率也顯著降低。在撰寫(xiě)本白皮書(shū)之時(shí)，微軟無(wú)法全面測(cè)試這些平臺(tái)，但是計(jì)劃在本 文檔的未來(lái)版本中增加相關(guān)測(cè)試結(jié)果。

返回頁(yè)首

報(bào)告緩存和存儲(chǔ)

影響 Reporting Services 實(shí)現(xiàn)方式的性能和容量的一大因素便是：用戶是通過(guò)從源系統(tǒng)中取得數(shù)據(jù)來(lái)實(shí)時(shí)生成報(bào)告，還是使用緩存或快照數(shù)據(jù)生成報(bào)告。本節(jié)內(nèi)容介紹了一些選項(xiàng)以及這些選項(xiàng)對(duì)性能造成的潛在影響。

緩存實(shí)例

Report Server 有兩級(jí)緩存：

1.

當(dāng) Report Server 生成報(bào)告時(shí)，它從 Report Server 目錄中取得報(bào)告定義并從數(shù)據(jù)源獲取報(bào)告數(shù)據(jù)。然后，它創(chuàng)建一份臨時(shí)報(bào)告格式，該報(bào)告保存在會(huì)話緩存中并寫(xiě)入 ReportServerTempDB 數(shù)據(jù)庫(kù)。它使用該版本（緩存實(shí)例）創(chuàng)建和呈現(xiàn)最終的報(bào)告。 對(duì)于完全“實(shí)時(shí)”報(bào)告，它會(huì)對(duì)每份報(bào)告重復(fù)此過(guò)程。但是，也可以將對(duì)已處理過(guò)的報(bào)告的后續(xù)請(qǐng)求定向到緩存實(shí)例。這樣可顯著縮短取得數(shù)據(jù)和創(chuàng)建報(bào)告所需的時(shí)間。

2.

Report Server 還會(huì)嘗試對(duì)內(nèi)存中或文件系統(tǒng)的臨時(shí)目錄下的緩存（或快照）報(bào)告的輸出格式進(jìn)行緩存。如果請(qǐng)求的結(jié)果在輸出緩存中找到，便可以同時(shí)繞過(guò)處理和呈現(xiàn)步驟，因此 可實(shí)現(xiàn)非常優(yōu)異的性能。有關(guān)如何確定所使用緩存的類(lèi)型的更多信息，請(qǐng)參見(jiàn)有關(guān)性能計(jì)數(shù)器的附錄 B。

緩存最終會(huì)過(guò)期，并因此導(dǎo)致 Report Server 收集新鮮的數(shù)據(jù)。可根據(jù)預(yù)定義的時(shí)間間隔、日程安排（特定于報(bào)告或共享）或強(qiáng)制過(guò)期來(lái)控制緩存過(guò)期時(shí)間。

緩存報(bào)告對(duì)存儲(chǔ)區(qū)會(huì)產(chǎn)生影響，雖然 SQL Server 2005 Reporting Services 以很緊湊的格式保存數(shù)據(jù)并且對(duì)數(shù)據(jù)進(jìn)行了壓縮。在確定所要維護(hù)的緩存或快照映像的數(shù)量時(shí)，請(qǐng)考慮以下因素：

?	創(chuàng)建緩存實(shí)例時(shí)應(yīng)用的查詢參數(shù)。如果您需要一份帶有不同查詢參數(shù)的報(bào)告，Reporting Services 將生成另外一個(gè)緩存實(shí)例。
?	查詢（過(guò)濾器）中未使用的報(bào)告參數(shù)可以用來(lái)創(chuàng)建不同于緩存實(shí)例的報(bào)告版本。

報(bào)告快照

快照指的是以更加持久的方式保存的同一份臨時(shí)報(bào)告格式。例如，快照可以保存在 Report Server 目錄中，而不是保存到 ReportServerTempDB 數(shù)據(jù)庫(kù)。此外，目錄還可保有作為報(bào)告歷史的多個(gè)臨時(shí)版本，因此允許用戶在這些版本中做出選擇。

SQL Server 2005 Reporting Services 自動(dòng)對(duì)目錄中的快照進(jìn)行壓縮。也可以將快照映像保存到本地文件系統(tǒng)中。

以下章節(jié)重點(diǎn)介紹了使用緩存實(shí)例、壓縮快照以及文件系統(tǒng)存儲(chǔ)三種方式對(duì)性能的映像。

緩存實(shí)例

提高 Reporting Services 部署的容量和伸縮能力的一種方法便是：避免使用實(shí)時(shí)數(shù)據(jù)來(lái)執(zhí)行報(bào)告。如果能達(dá)到相同的目的，那么可以轉(zhuǎn)而使用緩存數(shù)據(jù)來(lái)執(zhí)行報(bào)告。

圖 5 中的圖形顯示了檢索、處理和呈現(xiàn)一個(gè)包含 150 行數(shù)據(jù)的報(bào)告所花費(fèi)的時(shí)間（包括針對(duì)實(shí)時(shí)數(shù)據(jù)和緩存數(shù)據(jù)的兩種結(jié)果）。

?

圖 5：150-K 行的簡(jiǎn)單報(bào)告的時(shí)間計(jì)算結(jié)果
查看大圖

綜合來(lái)看，這些數(shù)字表明：對(duì) Reporting Services 使用實(shí)時(shí)數(shù)據(jù)時(shí)，需要的時(shí)間是使用緩存數(shù)據(jù)的 2.61 倍。返回大量實(shí)時(shí)數(shù)據(jù)的報(bào)告所需的資源遠(yuǎn)遠(yuǎn)超出使用緩存數(shù)據(jù)的報(bào)告。

在系統(tǒng)使用高峰的幾個(gè)小時(shí)內(nèi)，要求最終用戶避免運(yùn)行實(shí)時(shí)報(bào)告是不切實(shí)際的。用戶經(jīng)常不會(huì)意識(shí)到運(yùn)行這樣的報(bào)告會(huì)對(duì)系統(tǒng)性能和其他系統(tǒng)用戶造成何種影響。為了提高系統(tǒng)容量和響應(yīng)速度，一些可以考慮傳達(dá)給用戶的“好公民”做法包括：

?	盡可能避免讓報(bào)告檢索或執(zhí)行大量實(shí)時(shí)數(shù)據(jù)。轉(zhuǎn)而使用緩存數(shù)據(jù)。
?	如果無(wú)法完全避免使用實(shí)時(shí)數(shù)據(jù)，至少試著限制這種報(bào)告的運(yùn)行數(shù)量，尤其是在高峰時(shí)段。
?	如果可以使用緩存數(shù)據(jù)生成報(bào)告，可以將這些報(bào)告設(shè)定為在非高峰時(shí)段刷新緩存，以避免影響其他用戶。

經(jīng)過(guò)壓縮的快照存儲(chǔ)

在 SQL Server 2005 Reporting Services 中，管理員們可以指定快照數(shù)據(jù)的存儲(chǔ)位置和存儲(chǔ)方式。

使用快照能夠顯著改善報(bào)告性能，但是會(huì)占用數(shù)據(jù)庫(kù)的存儲(chǔ)空間。為了在存儲(chǔ)空間和性能之間求得平衡，Reporting Services 提供了一個(gè)由系統(tǒng)屬性控制的壓縮選項(xiàng)。默認(rèn)設(shè)置是對(duì)快照數(shù)據(jù)和報(bào)告定義進(jìn)行壓縮。也可以關(guān)閉壓縮功能。

例如，在一個(gè) 20,000 行的報(bào)告中，SQL 的快照壓縮功能可以將快照大小降低 20%。更小的體積不僅意味著可節(jié)省 Report Server 目錄中的大量存儲(chǔ)空間，而且還能極大降低 Report Server 和目錄間的網(wǎng)絡(luò)流量。

文件系統(tǒng)存儲(chǔ)

用于存儲(chǔ)快照的另一個(gè)選項(xiàng)是：使用文件系統(tǒng) (FS) 存儲(chǔ)。此設(shè)置不受 SQL 壓縮選項(xiàng)的影響，因?yàn)閿?shù)據(jù)保存在文件系統(tǒng)中。

FS 快照存儲(chǔ)非常適用于 Reporting Services 的遠(yuǎn)程目錄和橫向伸縮部署方式。如果啟用了 FS 存儲(chǔ)，快照數(shù)據(jù)可以存放在 Report Server 的本地文件系統(tǒng)中。這使得 Report Server 可以避免為支持會(huì)話和報(bào)告請(qǐng)求而往返于目錄。

可以通過(guò)更改 RSReportServer.config 文件中的 WebServiceUseFileShareStorage 鍵值來(lái)控制 FS 的使用。若要開(kāi)啟 FS，請(qǐng)根據(jù)如下所示更改該值：

<Add Key="WebServiceUseFileShareStorage" Value="true" />

若要關(guān)閉 FS，只需將該鍵值設(shè)置回“false”。

注意：默認(rèn)情況下，FS 將快照數(shù)據(jù)保存到文件系統(tǒng)的 C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.instanceReporting ServicesRSTempFiles 目錄下。CleanupCycleMinutes，位于 RSReportServer.config 文件中，控制未使用的 FS 數(shù)據(jù)的刪除頻率。對(duì)于操作頻繁的系統(tǒng)，在設(shè)置該文件夾的存儲(chǔ)空間需求時(shí)應(yīng)十分謹(jǐn)慎，以免超出了可用的存儲(chǔ)空間限制。

如 果 Report Server 使用本地目錄而不是遠(yuǎn)程目錄，那么它不會(huì)利用文件系統(tǒng)存儲(chǔ)。快照數(shù)據(jù)已經(jīng)保存在本地的 SQL Server 關(guān)系型數(shù)據(jù)庫(kù)中，而該數(shù)據(jù)庫(kù)則針對(duì)數(shù)據(jù)的存儲(chǔ)和檢索進(jìn)行了充分優(yōu)化。如果配置本地目錄系統(tǒng)以使其使用文件系統(tǒng)存儲(chǔ)，會(huì)造成存儲(chǔ)空間和快照管理出現(xiàn)不必要的 冗余。

壓縮和文件系統(tǒng)存儲(chǔ)的影響

微軟已經(jīng)在 4 顆處理器的遠(yuǎn)程系統(tǒng)上測(cè)試了壓縮和 FS 快照存儲(chǔ)對(duì)性能的影響。兩種技術(shù)都能提高系統(tǒng)在重負(fù)載情況下的處理能力。雖然壓縮會(huì)加重處理器的負(fù)擔(dān)，但它也降低了報(bào)告服務(wù)器和目錄之間的網(wǎng)絡(luò)流量。

表 5

?	每秒的平均請(qǐng)求數(shù)（與基準(zhǔn)數(shù)據(jù)的比值）	每小時(shí)的頁(yè)面瀏覽量（與基準(zhǔn)數(shù)據(jù)的比值）	峰值會(huì)話數(shù)（與基準(zhǔn)數(shù)據(jù)的比值）
未壓縮	基準(zhǔn)	基準(zhǔn)	基準(zhǔn)
SQL 壓縮	基準(zhǔn)	109%	基準(zhǔn)
文件系統(tǒng)存儲(chǔ)	126%	129%	113%

文件系統(tǒng)存儲(chǔ)允許您支持更多數(shù)量的用戶會(huì)話，同時(shí)不會(huì)增加系統(tǒng)的響應(yīng)時(shí)間。顯而易見(jiàn)，FS 設(shè)置具有最佳的伸縮性和處理能力。在測(cè)試 4 處理器的遠(yuǎn)程目錄系統(tǒng)時(shí)，微軟通過(guò)開(kāi)啟快照數(shù)據(jù)的文件系統(tǒng)存儲(chǔ)，將能夠支持的并發(fā)用戶會(huì)話數(shù)量提高了 13%。

關(guān)鍵點(diǎn)

?	通過(guò)使用更多緩存實(shí)例和快照來(lái)代替實(shí)時(shí)報(bào)告，可以切實(shí)有效地提高現(xiàn)有系統(tǒng)的容量。
?	對(duì)于大容量報(bào)告環(huán)境，使用文件系統(tǒng)快照可為橫向伸縮的遠(yuǎn)程服務(wù)器實(shí)現(xiàn)方式提供盡可能高的處理能力和盡可能快的響應(yīng)速度。

返回頁(yè)首

性能優(yōu)化最佳實(shí)踐

本部分內(nèi)容總結(jié)了容量規(guī)劃和性能優(yōu)化的指導(dǎo)原則和最佳實(shí)踐。

選擇一種配置

通過(guò)閱讀縱向伸縮和橫向伸縮指南，各種系統(tǒng)配置的報(bào)告能力各不相同這一點(diǎn)變得愈加清晰了。

最 基本的配置方式是使用本地目錄的 2 處理器 Report Server。而最高端的配置是橫向伸縮配置，它具有強(qiáng)大的伸縮能力和優(yōu)異的性能表現(xiàn)。雖然本白皮書(shū)中的測(cè)試僅僅討論了使用遠(yuǎn)程目錄的四臺(tái)配備 2 顆處理器的 Report Server 的橫向伸縮配置，但是使用更大型的橫向伸縮配置也很容易。

在這兩種極端之間，您可以選擇遠(yuǎn)程承載目錄，向本地或遠(yuǎn)程實(shí)現(xiàn)方式添加處理器，或者以“Web 園”的方式將處理能力分配給單個(gè)系統(tǒng)中的多個(gè)處理器。

在為環(huán)境選擇正確的配置方式時(shí)，首先需要確定您對(duì)性能的特定要求。以下是可以使用的一些簡(jiǎn)單指南：

?	如果您的系統(tǒng)可以容納更多內(nèi)存，請(qǐng)?zhí)砑舆@些內(nèi)存。這是因?yàn)閮?nèi)存占用是您可能遇到的第一個(gè)瓶頸。
?	如果您擔(dān)心伸縮性并且運(yùn)行一個(gè)本地目錄系統(tǒng)，要做的第一件事情就是在單獨(dú)的服務(wù)器上承載報(bào)告目錄。只有將目錄分隔出去才能通過(guò)增加處理器而顯著提高性能和負(fù)載方面的伸縮性。
?	對(duì)于 4 顆處理器以下的系統(tǒng)，縱向伸縮和橫向伸縮都是不錯(cuò)的方法。超過(guò)這個(gè)數(shù)字之后，橫向伸縮可能是最安全和最靈活的伸縮途徑。但是，我們并沒(méi)有對(duì)大型的 SMP 系統(tǒng)進(jìn)行測(cè)試。

橫向伸縮配置方式中的橫向伸縮讓您能夠避免某些過(guò)程——例如設(shè)計(jì)特別報(bào)告和預(yù)先計(jì)劃的報(bào)告操作——干擾交互式報(bào)告的運(yùn)行。例如：

?	拿出一臺(tái)特定的 Report Server 作為所有 Report Builder 請(qǐng)求的前端，使用其余 Report Servers 處理交互式報(bào)告。
?	拿出一臺(tái)或多臺(tái) Report Servers 用于定期訂閱或由事件驅(qū)動(dòng)的報(bào)告生成工作。

通用性能優(yōu)化技巧

因 為 Report Server 目錄承載在 SQL Server 上，如果懷疑數(shù)據(jù)庫(kù)存在性能問(wèn)題，可以應(yīng)用針對(duì) SQL Server 數(shù)據(jù)庫(kù)服務(wù)器的性能優(yōu)化而提出的建議。這可能涉及從中獲取構(gòu)建報(bào)告所需數(shù)據(jù)的源數(shù)據(jù)庫(kù)，也可能涉及用于支持所有報(bào)告服務(wù)實(shí)現(xiàn)的目錄數(shù)據(jù)庫(kù)?？梢酝ㄟ^(guò)以下地 址找到有關(guān) SQL Server 優(yōu)化的詳細(xì)信息：http://www.microsoft.com/technet/ ，SQL Server 聯(lián)機(jī)圖書(shū)的“數(shù)據(jù)層：一條數(shù)據(jù)庫(kù)優(yōu)化途徑”和 的“性能評(píng)估”章節(jié)也提供了相關(guān)優(yōu)化信息。

以下是一些通用的性能優(yōu)化技巧，在優(yōu)化 Reporting Services 時(shí)請(qǐng)務(wù)必謹(jǐn)記在心：

?	優(yōu) 化您的報(bào)告查詢。通常，大部分報(bào)告執(zhí)行時(shí)間都用來(lái)執(zhí)行查詢和取得結(jié)果。如果您正在使用 SQL Server，諸如 Query Analyzer 和 Profiler 這樣的工具可幫助您優(yōu)化查詢。此外，Database Tuning Advisor 也可為數(shù)據(jù)庫(kù)建議更好的索引方式。您還應(yīng)該考慮使用 Analysis Services 提高性能。
?	如果您在報(bào)告中不需要某些數(shù)據(jù)，請(qǐng)不要取得這些數(shù)據(jù)。使用數(shù)據(jù)庫(kù)操作（如篩選、分組和匯集）可減少報(bào)告處理的數(shù)據(jù)量并因此提高性能。
?	讓報(bào)告的大小和復(fù)雜性保持適度。很少有用戶真的希望查看 1000 頁(yè)的報(bào)告。如果您發(fā)現(xiàn)需要處理大型報(bào)告，請(qǐng)想辦法將它們分解為較小的數(shù)據(jù)塊。
?	如 果在單用戶的情況下性能也很糟糕，請(qǐng)檢查 ASP.NET 類(lèi)別下的 Application Restarts 計(jì)數(shù)器。已知某些防病毒軟件會(huì)“修改”配置文件，并因此導(dǎo)致 Application Domain 在 Report Server Web 服務(wù)中頻繁重新啟動(dòng)。有關(guān)更多信息，請(qǐng)?jiān)?http://support.microsoft.com/ 上搜索有關(guān)防病毒和 ASP.NET 的文章。
?	如果在停止活動(dòng)一段時(shí)間后首次訪問(wèn) Web 服務(wù)時(shí)性能緩慢，請(qǐng)?jiān)?IIS Manager 的 Application 的 Performance 選項(xiàng)卡上禁用空閑時(shí)間超時(shí)。
?	盡可能使用緩存/快照數(shù)據(jù)執(zhí)行報(bào)告（與實(shí)時(shí)數(shù)據(jù)相比而言）。
?	將不重要的后臺(tái)處理限制到非高峰時(shí)間段執(zhí)行，以避免與在線用戶爭(zhēng)奪資源。
?	如果您的報(bào)告服務(wù)器擁有 4GB 內(nèi)存，請(qǐng)記住在 C:boot.ini 中設(shè)置 /3GB 開(kāi)關(guān)，以便應(yīng)用程序能夠使用這些內(nèi)存。
?	如果在用戶使用系統(tǒng)時(shí)執(zhí)行諸如清理 Reporting Services 中的會(huì)話這樣的維護(hù)管理工作，代價(jià)將十分昂貴。有關(guān)如何調(diào)整 RSReportServer.config 中的 CleanupCycleMinutes 時(shí)間間隔的說(shuō)明，請(qǐng)參見(jiàn)附錄 A.
?	在多個(gè)數(shù)據(jù)文件上創(chuàng)建 Report Server 目錄。可以將數(shù)據(jù)和日志放在不同的物理磁盤(pán)上來(lái)實(shí)現(xiàn)這個(gè)目的。具體做法請(qǐng)參見(jiàn)附錄 A.

使用 Web 園

在 Microsoft? Windows? 2003 Server 上，可以通過(guò)配置“最大工作進(jìn)程數(shù)”(Maximum Number of Worker Processes） 設(shè)置來(lái)提高伸縮性。

為 了找到該 Internet 信息服務(wù) (IIS) 設(shè)置，請(qǐng)打開(kāi) IIS Manager 工具并查看分配給每個(gè) Reporting Services 虛擬目錄 (vdir) 的應(yīng)用程序池的屬性。默認(rèn)情況下，這些屬性名為 Reports 和 ReportServer。您首先必須通過(guò)右擊 vdir 并選擇屬性選項(xiàng)來(lái)確定分配給每個(gè) vdir 的應(yīng)用程序池。分配的應(yīng)用程序池將出現(xiàn)在“虛擬目錄”選項(xiàng)卡的底部。

在確定了正在使用的應(yīng)用程序池之后，下一步便是打開(kāi)所分配應(yīng)用程序池的 屬性。也可以通過(guò) IIS Manager 訪問(wèn)該屬性。接著，找到“最大工作進(jìn)程數(shù)”設(shè)置。通過(guò)右擊分配的應(yīng)用程序池，選擇屬性選項(xiàng)并查看“性能”選項(xiàng)卡，可找到該設(shè)置。“最大工作進(jìn)程數(shù)”設(shè)置出 現(xiàn)在“性能”選項(xiàng)卡的底部。

在配備 2 顆處理器和 4 顆處理器的系統(tǒng)上，提高工作進(jìn)程的最大數(shù)量對(duì)系統(tǒng)容量和穩(wěn)定性具有積極的影響。具體來(lái)說(shuō)，在配備 4 顆處理器的系統(tǒng)上，將工作進(jìn)程的最大數(shù)目從 1 更改為 4 可使 Report Processor 在性能出現(xiàn)下降之前處理更多的并發(fā)會(huì)話負(fù)載。更改該設(shè)置對(duì)配備 2 顆處理器的遠(yuǎn)程系統(tǒng)的影響小于配備 4 顆處理器的遠(yuǎn)程系統(tǒng)。

如果您的 Reporting Services 所運(yùn)行的系統(tǒng)配備的處理器數(shù)量多于 4 顆，32 位尋址能力可能無(wú)法提供足夠的內(nèi)存供多于 4 顆的處理器使用。您應(yīng)執(zhí)行更多測(cè)試來(lái)確認(rèn)這些結(jié)果。

返回頁(yè)首

其他工作負(fù)載的優(yōu)化

雖然本白皮書(shū)主要關(guān)注交互式工作負(fù)載，但以下部分也提供了有關(guān)預(yù)定報(bào)告和特別報(bào)告負(fù)載的提示和技巧。未來(lái)版本的白皮書(shū)也將提供針對(duì)這些應(yīng)用情境的附加指南。

預(yù)定報(bào)告的交付性能

預(yù) 定報(bào)告或訂閱報(bào)告按照預(yù)先計(jì)劃的時(shí)間運(yùn)行，因此接受您的控制。如果 Reporting Services 環(huán)境提供了預(yù)定報(bào)告和按需報(bào)告，可將訂閱報(bào)告的處理工作隔離到一臺(tái)單獨(dú)的 Report Server 上。然后，可像其他 Report Server 一樣訪問(wèn)同一個(gè)目錄，但是它并不處理交互式請(qǐng)求。這樣，訂閱報(bào)告的處理工作不會(huì)對(duì)按需報(bào)告的處理過(guò)程造成影響。

與交互式負(fù)載類(lèi)似，預(yù)定操作的伸縮性也可以借助橫向伸縮配置而得到提高。所有后臺(tái)操作都放在目錄數(shù)據(jù)庫(kù)的一個(gè)隊(duì)列中，與之連接的每臺(tái)服務(wù)器都從中取出一個(gè)作業(yè)進(jìn)行處理。

特別報(bào)告的性能

SQL Server 2005 Reporting Services 提供了一個(gè)特別報(bào)告工具，允許企業(yè)用戶以交互方式創(chuàng)建他們自己的報(bào)告。Report Builder 包括一個(gè)業(yè)務(wù)查詢模型，用戶無(wú)需深入了解底層數(shù)據(jù)源即可構(gòu)造出報(bào)告。

在使用 Report Builder 時(shí)存在一個(gè)風(fēng)險(xiǎn)，即企業(yè)用戶在構(gòu)造和運(yùn)行復(fù)雜的資源密集型報(bào)告時(shí)會(huì)占用大量資源，這不僅會(huì)影響 Report Server，而且還會(huì)影響到源系統(tǒng)。

如果您希望廣泛使用 Report Builder，可以采取某些步驟保護(hù)整體系統(tǒng)性能不受損害。例如：

?	將 Report Builder 會(huì)話隔離到一臺(tái)專(zhuān)用的 Report Server 上，防止意料之外的負(fù)載對(duì)其他用戶的交互式報(bào)告處理造成影響。
?	不 要讓 Report Builder 會(huì)話直接與生產(chǎn)環(huán)境中的 OLTP 系統(tǒng)進(jìn)行聯(lián)系。相反，應(yīng)將它們導(dǎo)向生產(chǎn)型數(shù)據(jù)源的副本。根據(jù)所需延遲時(shí)間的不同，可以使用數(shù)據(jù)庫(kù)鏡像和復(fù)制這樣的技術(shù)來(lái)構(gòu)建副本，或者使用 Integration Services 創(chuàng)建數(shù)據(jù)集市。通過(guò)這種方式，可避免不受控制的報(bào)告構(gòu)建活動(dòng)對(duì)生產(chǎn)系統(tǒng)產(chǎn)生負(fù)面影響。

返回頁(yè)首

運(yùn)行您自己的性能測(cè)試

雖 然，模擬真實(shí)的負(fù)載條件不是一件輕松的工作，但我們強(qiáng)烈建議花時(shí)間這樣做。許多系統(tǒng)在投入生產(chǎn)環(huán)境后遭遇到性能問(wèn)題，其原因均在于沒(méi)有在具體實(shí)施之前執(zhí)行 足夠的壓力測(cè)試。正確的容量規(guī)劃和足以支持生產(chǎn)負(fù)載的充足服務(wù)器是在系統(tǒng)投入實(shí)際運(yùn)行前避免各種主要問(wèn)題的最佳方法。至少，您的部署計(jì)劃中應(yīng)包括以下兩項(xiàng) 工作：

?	模擬您的 Reporting Services 系統(tǒng)在投入生產(chǎn)環(huán)境后可能遇到的有代表性的負(fù)載。
?	在與計(jì)劃中的生產(chǎn)環(huán)境基本相同的環(huán)境下執(zhí)行測(cè)試。

通 過(guò)執(zhí)行上述兩項(xiàng)工作并記錄在“分析指標(biāo)”一節(jié)中討論的指標(biāo)，可以在規(guī)劃部署時(shí)建立真實(shí)的性能基準(zhǔn)。這樣的基準(zhǔn)在將來(lái)檢驗(yàn)應(yīng)用程序、配置或硬件的更改效果時(shí) 十分有用。當(dāng)使用某個(gè)已建立的基準(zhǔn)時(shí)，可以通過(guò)重新運(yùn)行相同的測(cè)試來(lái)驗(yàn)證擬議的更改是否會(huì)對(duì)性能造成負(fù)面影響。在任何時(shí)候，只要對(duì)系統(tǒng)進(jìn)行了大的更改，都 應(yīng)重新建立性能基準(zhǔn)。

微軟及第三方廠商提供了眾多壓力測(cè)試工具，可使用它們建立性能基準(zhǔn)。Microsoft? Visual Studio? 2005 Team Test Edition 包括了用于執(zhí)行網(wǎng)站負(fù)載測(cè)試的工具。更多相關(guān)信息，請(qǐng)?jiān)L問(wèn)：http://msdn.microsoft.com/.
本白皮書(shū)的附錄介紹了大量的性能計(jì)數(shù)器，幫助您順利執(zhí)行測(cè)試。

性能因素

在確定您的性能需求時(shí)，首先必須理解您對(duì)工作負(fù)載的需要。有些用戶使用 Reporting Services 并通過(guò)企業(yè)門(mén)戶提供按需報(bào)告，而有些用戶則需要處理和提供預(yù)定報(bào)告。此外，有些用戶還支持使用 Report Builder 創(chuàng)建特別報(bào)告。

影響工作負(fù)載和性能的其他因素包括：

?	同時(shí)提出報(bào)告請(qǐng)求的用戶的數(shù)量 同時(shí)活動(dòng)的會(huì)話數(shù)量越多，消耗的計(jì)算機(jī)資源也就越多。
?	報(bào)告定義的規(guī)模和復(fù)雜性 與處理行數(shù)很少的簡(jiǎn)單報(bào)告相比，處理包含大量行的報(bào)告顯然需要更多資源。
?	是使用緩存或快照數(shù)據(jù)執(zhí)行報(bào)告，還是使用實(shí)時(shí)數(shù)據(jù)執(zhí)行報(bào)告。 使用緩存/快照數(shù)據(jù)執(zhí)行的報(bào)告占用的資源顯著少于使用實(shí)時(shí)數(shù)據(jù)的報(bào)告。此外，使用緩存報(bào)告可減少?gòu)闹蝎@取數(shù)據(jù)的源系統(tǒng)承擔(dān)的負(fù)載
?	Reporting Services 從中獲取報(bào)告數(shù)據(jù)的源數(shù)據(jù)系統(tǒng)的性能 如果針對(duì)這些系統(tǒng)執(zhí)行查詢時(shí)速度緩慢，則說(shuō)明您的報(bào)告也將運(yùn)行緩慢。
?	呈現(xiàn)報(bào)告時(shí)請(qǐng)求的格式 PDF 或 Microsoft? Excel? 這樣的格式比 HTML 格式更加耗用資源。
?	承載目錄的數(shù)據(jù)庫(kù)服務(wù)器的性能 與源數(shù)據(jù)系統(tǒng)類(lèi)似，如果承載目錄的系統(tǒng)十分緩慢，那么報(bào)告的執(zhí)行速度也將十分緩慢。

正在進(jìn)行設(shè)計(jì)或需要由用戶進(jìn)行配置的許多事項(xiàng)也會(huì)影響報(bào)告的性能。這包括：

?	Reporting Services 配置文件、IIS 以及 Microsoft? Windows 操作系統(tǒng)中的應(yīng)用程序設(shè)置。
?	支持報(bào)告應(yīng)用程序的硬件配置和設(shè)計(jì)。
?	諸如交付基礎(chǔ)結(jié)構(gòu)這樣的外部因素，包括網(wǎng)絡(luò)容量、用于交付訂閱的電子郵件服務(wù)器的性能或者是文件共享的可用性和性能。

若要正確規(guī)劃任何 Reporting Services 部署的容量，首先需要理解您的工作負(fù)載具有的特性。您的工作負(fù)載可能隨時(shí)間發(fā)生變化，并且在每月、每周或每日的使用中發(fā)生波動(dòng)，具體情況則取決于各種業(yè)務(wù)因素的影響。

分析指標(biāo)

當(dāng)您確定系統(tǒng)的性能基準(zhǔn)時(shí)，應(yīng)該依據(jù)有意義的指標(biāo)來(lái)進(jìn)行確定。微軟在其伸縮性測(cè)試中使用了如下指標(biāo)：

?	Simultaneous Session（并發(fā)會(huì)話）
?	Average Requests per Second（每秒的平均請(qǐng)求數(shù)）
?	Median Response Time（中值響應(yīng)時(shí)間）
?	Total Page Views per Minute（每分鐘的總頁(yè)面瀏覽量）

Simultaneous Session指標(biāo)是確定其他指標(biāo)的優(yōu)秀變量。例如，可以從 100 個(gè)并發(fā)會(huì)話開(kāi)始，并以每次后續(xù)運(yùn)行增加 100 個(gè)的速度進(jìn)行增長(zhǎng)，以這種方式產(chǎn)生測(cè)試負(fù)載。

The Average Requests per Second?指標(biāo)有助于您理解每個(gè)給定的系統(tǒng)配置能夠成功支持多少個(gè)并發(fā)的 Web 請(qǐng)求。只要系統(tǒng)沒(méi)有在特定負(fù)載下表現(xiàn)的難以為繼，每次系統(tǒng)測(cè)試都應(yīng)該為收到的所有請(qǐng)求提供同樣的服務(wù)。

如 果以每秒的請(qǐng)求數(shù)相對(duì)于并發(fā)會(huì)話數(shù)繪制圖形，可以找到曲線的頂點(diǎn)，該頂點(diǎn)代表了系統(tǒng)能夠應(yīng)付的“每秒平均請(qǐng)求數(shù)”的最大值。此圖形可幫助您了解每個(gè)系統(tǒng)能 夠支持的每秒請(qǐng)求數(shù)峰值和最大會(huì)話數(shù)。顯然，如果希望了解“每分鐘平均請(qǐng)求數(shù)”或“每小時(shí)平均請(qǐng)求數(shù)”，可以輕松地對(duì)“每秒平均請(qǐng)求數(shù)”進(jìn)行外推。

“中值響應(yīng)時(shí)間”（收到最后一個(gè)字節(jié)的時(shí)間，或者說(shuō) TTLB）是一個(gè)常見(jiàn)指標(biāo)，用來(lái)了解 Reporting Services 需要花費(fèi)多長(zhǎng)的時(shí)間才能對(duì)報(bào)告請(qǐng)求做出響應(yīng)。顯然，響應(yīng)時(shí)間越低越好

“每分鐘的總頁(yè)面瀏覽量”可幫助我們了解每種系統(tǒng)配置能夠支持的報(bào)告執(zhí)行數(shù)量以及后續(xù)的頁(yè)面瀏覽量。實(shí)際上，可以獲得有關(guān)頁(yè)面瀏覽量的更詳細(xì)信息。這些信息包括：

?	初始報(bào)告請(qǐng)求 為了獲得此信息，可模擬發(fā)出初始請(qǐng)求以查看報(bào)告第一頁(yè)的用戶。初始請(qǐng)求通常比后續(xù)頁(yè)面瀏覽請(qǐng)求要花費(fèi)更長(zhǎng)的時(shí)間。
?	后續(xù)頁(yè)面瀏覽 為了獲得此信息，可模擬請(qǐng)求查看報(bào)告的后續(xù)頁(yè)面的用戶。
?	總頁(yè)面瀏覽量 這是所有初始報(bào)告請(qǐng)求 (Initial Report Request)的總和，再加上所有后續(xù)頁(yè)面瀏覽量 (Subsequent Page Views），這是一個(gè)綜合值，代表所執(zhí)行頁(yè)面瀏覽請(qǐng)求的整體數(shù)量。

思考時(shí)間

在實(shí)際工作中，用戶在查看報(bào)告結(jié)果和提交查看其他頁(yè)或運(yùn)行其他報(bào)告的后續(xù)請(qǐng)求之間通常有一段等待時(shí)間。

微軟在內(nèi)部測(cè)試中選擇了一個(gè)在 25 - 35 秒之間的隨機(jī)思考時(shí)間。該思考時(shí)間應(yīng)當(dāng)是比較真實(shí)的，因?yàn)槲覀兗俣▓?zhí)行報(bào)告的典型用戶在瀏覽后續(xù)頁(yè)面之前都會(huì)花費(fèi)一定的時(shí)間查看報(bào)告結(jié)果。

命名用戶總數(shù)和并發(fā)活動(dòng)會(huì)話

命名用戶總數(shù)并不等同于主動(dòng)向 Reporting Services 發(fā)出請(qǐng)求的并發(fā)會(huì)話的數(shù)量。在規(guī)劃您自己的部署時(shí)，請(qǐng)注意以下幾點(diǎn)：

?	命名用戶總數(shù)代表了獲得授權(quán)和具有訪問(wèn) Report Server 的潛在能力的所有用戶的總和。
?	命名用戶總數(shù)中只有一部分代表給定時(shí)間內(nèi)系統(tǒng)上以交互形式開(kāi)展工作的并發(fā)會(huì)話。
?	因?yàn)榇嬖谒伎紩r(shí)間，這其中只有一部分屬于在給定時(shí)間同時(shí)向 Report Server 發(fā)出請(qǐng)求的并發(fā)活動(dòng)會(huì)話。

返回頁(yè)首

總結(jié)

Microsoft SQL Server Reporting Services 的設(shè)計(jì)目標(biāo)是：滿足各種組織的需要，提供經(jīng)濟(jì)、靈活的報(bào)告能力，優(yōu)化企業(yè)生產(chǎn)力。

Reporting Services 構(gòu)建在 .NET 平臺(tái)和 Windows Server 系統(tǒng)的基礎(chǔ)之上，其伸縮性和可靠性足以支持要求苛刻的企業(yè)環(huán)境。它具有模塊化的可擴(kuò)展架構(gòu)，以及開(kāi)放的接口和 API，幾乎能夠集成到所有 IT 環(huán)境之中。通過(guò)這種方式，它有效地將人員與遍布企業(yè)各處的信息聯(lián)系在一起。

大多數(shù)情況下，增加計(jì)算機(jī)資源都能夠以近乎線性的方式提高 Reporting Services 部署的伸縮性。增加系統(tǒng)容量的第一個(gè)合乎邏輯的步驟是將 Report Server 目錄分隔到遠(yuǎn)程服務(wù)器上。然后，必須決定是以縱向伸縮還是橫向伸縮的方式來(lái)提高 Reporting Services 的處理能力。微軟執(zhí)行的測(cè)試表明，這兩種方式都十分有效。因此，您的選擇在很大程度取決于您的經(jīng)濟(jì)能力和喜好。

無(wú)論最終選擇何種伸縮途徑，建立您自己的自定義基準(zhǔn)都十分重要。這樣，您可以在更改配置后，監(jiān)視系統(tǒng)的處理能力是有所提高還是有所下降。只有測(cè)試能夠反映您的特定用戶需求的工作負(fù)載，才能夠確定所做更改對(duì)系統(tǒng)造成的影響是積極的還是消極的。

微軟提供了幾個(gè)工具（請(qǐng)參見(jiàn)本白皮書(shū)中的介紹），幫助您測(cè)試和監(jiān)視 Reporting Services 的性能表現(xiàn)。通過(guò)使用本白皮書(shū)提供的指導(dǎo)原則，您應(yīng)該已經(jīng)可以成功地對(duì) Reporting Services 部署進(jìn)行簡(jiǎn)單的容量規(guī)劃，并有效地監(jiān)視其后續(xù)操作。

返回頁(yè)首

附錄 A：系統(tǒng)配置設(shè)置

當(dāng)配置 Report Server 系統(tǒng)時(shí)，應(yīng)該查看以下設(shè)置和選項(xiàng)以優(yōu)化性能。在創(chuàng)建基準(zhǔn)性能量度時(shí)，它們尤其顯得重要。

CleanupCycleMinutes

CleanupCycleMinutes 字段控制 Reporting Services 執(zhí)行特定維護(hù)和管理任務(wù)（例如清理過(guò)期會(huì)話和孤立會(huì)話）的頻率。在繁忙時(shí)段執(zhí)行這些任務(wù)的開(kāi)銷(xiāo)可能非常之大。如果有可用的磁盤(pán)空間來(lái)在更長(zhǎng)期限內(nèi)存儲(chǔ)會(huì)話 數(shù)據(jù)，可提高 CleanupCycleMinutes 的值以降低維護(hù)管理工作的執(zhí)行頻率。您肯定還希望增加時(shí)間，以免它在運(yùn)行基準(zhǔn)性能測(cè)試時(shí)運(yùn)行。

CleanupCycleMinutes 字段位于 RSReportServer.config 文件中。默認(rèn)情況下，該文件位于 C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.InstanceReporting ServicesReportServer。默認(rèn)設(shè)置為 10.但是，微軟在自己的伸縮性測(cè)試中將其更改為 1200,以避免這些進(jìn)程在測(cè)試運(yùn)行過(guò)程中啟動(dòng)。

MaxActiveReqForOneUser

默 認(rèn)情況下，Reporting Services 會(huì)限制單個(gè)用戶可以同時(shí)運(yùn)行的未完成 URL 和 Web 服務(wù)請(qǐng)求的數(shù)量，以避免遭受拒絕服務(wù) (DOS) 攻擊。作為管理員，您可以提高此限制，讓每位用戶能夠同時(shí)打開(kāi)更多請(qǐng)求。當(dāng)?shù)竭_(dá)此設(shè)置的上限后，Report Server 自動(dòng)丟棄來(lái)自該用戶的后續(xù)請(qǐng)求。

此值也可以在 RSReportServer.config 文件中找到。默認(rèn)設(shè)置為 20。但是，根據(jù)您的測(cè)試環(huán)境中不重復(fù)用戶的數(shù)量，您可能必須增加該值。

當(dāng) SQL Server 與 Report Server 位于同一臺(tái)計(jì)算機(jī)上時(shí)，設(shè)置內(nèi)存配置的限額。

通 過(guò)讓 SQL Server “釘住”特定數(shù)量的內(nèi)存，可以規(guī)定由 SQL Server 和 Report Server 分別使用的內(nèi)存數(shù)量。為此，請(qǐng)將內(nèi)存的最大和最小數(shù)量設(shè)置為計(jì)算機(jī)的物理內(nèi)存的一部分。例如，如果計(jì)算機(jī)配備了 3 GB 內(nèi)存并且所有 Windows 應(yīng)用程序都可以使用這些內(nèi)存，可以讓 SQL Server 僅使用 1 GB 內(nèi)存，而讓 Reporting Services 使用剩余的內(nèi)存。

ReportServerTempDB 分區(qū)

對(duì) 于伸縮性測(cè)試，微軟創(chuàng)建了一個(gè)經(jīng)過(guò)分區(qū)的 ReportServerTempDB 數(shù)據(jù)庫(kù)，該數(shù)據(jù)庫(kù)包括 10 個(gè)不同的 1 GB 大小的文件以及 1 個(gè) 1 GB 大小的事務(wù)日志，以提高磁盤(pán) I/O 操作的并行度。如果在工作負(fù)載中使用快照?qǐng)?zhí)行測(cè)試，ReportServer 數(shù)據(jù)庫(kù)的分區(qū)也會(huì)大有益處。所有 11 個(gè)文件都分配到單個(gè) RAID 0+1 存儲(chǔ)設(shè)備上，以優(yōu)化目錄讀寫(xiě)操作的性能。下面是一個(gè) T-SQL 腳本示例，簡(jiǎn)單演示了如何實(shí)現(xiàn)上述目的。

use master drop database ReportServerTempDB go create database ReportServerTempDBON PRIMARY ( NAME = ReportServerTempDB1, FILENAME = 'C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.InstancedataReportServerTempDB1.mdf', SIZE = 1GB, FILEGROWTH = 20), ( NAME = ReportServerTempDB2, FILENAME = 'C:Program FilesMicrosoft SQL ServerMSSQLdataReportServerTempDB2.ndf', SIZE = 1GB, FILEGROWTH = 20), .. . ( NAME = ReportServerTempDB10, FILENAME = 'C:Program FilesMicrosoft SQL ServerMSSQL MSSQL.InstancedataReportServerTempDB10.ndf', SIZE = 1GB, FILEGROWTH = 20) LOG ON ( NAME = ReportServerTempDBLog, FILENAME = 'C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.InstancedataReportServerTempDB_Log.ldf', SIZE = 1GB, FILEGROWTH = 20) COLLATELatin1_General_CI_AS_KS_WS go use ReportServerTempDB exec sp_addrole ' RSExecRole' go 返回頁(yè)首

附錄 B：性能測(cè)量工具

本部分內(nèi)容介紹可用于測(cè)量和監(jiān)視 Reporting Services 性能的各種工具。

Windows 性能監(jiān)視器工具

可 使用集成化性能工具監(jiān)視用于監(jiān)視 Reporting Services 的性能計(jì)數(shù)器。運(yùn)行 Reporting Services 的所有 Microsoft? Windows? 操作系統(tǒng)都包括了該工具。監(jiān)視 Reporting Services 系統(tǒng)的特定性能計(jì)數(shù)器讓您能夠：

?	估計(jì)支持預(yù)期負(fù)載所需的系統(tǒng)要求。
?	創(chuàng)建性能基準(zhǔn)，以測(cè)量配置更改和應(yīng)用程序升級(jí)造成的影響。
?	監(jiān)視存在負(fù)載情況下的應(yīng)用程序性能，無(wú)論是真實(shí)負(fù)載還是模擬負(fù)載。
?	驗(yàn)證硬件升級(jí)是否按照預(yù)期對(duì)性能產(chǎn)生了積極的影響。
?	驗(yàn)證系統(tǒng)配置更改是否按照預(yù)期對(duì)性能產(chǎn)生了積極的影響。

如果需要在一臺(tái)計(jì)算機(jī)上監(jiān)視多個(gè) Report Server 實(shí)例，可以同時(shí)或單獨(dú)監(jiān)視這些實(shí)例。選擇要包括的實(shí)例是計(jì)數(shù)器添加過(guò)程的一部分。有關(guān)使用 Windows 附帶的性能工具的更多信息，請(qǐng)參見(jiàn)微軟 Windows 產(chǎn)品文檔。

若要訪問(wèn)性能工具

?	從“開(kāi)始”菜單上選擇“運(yùn)行”。
?	在“打開(kāi)”文本框中輸入“perfmon”，然后單擊“確定”。
?	在性能監(jiān)視器工具中，在左側(cè)窗格里選擇 System Monitor 對(duì)象，然后右擊“性能”圖表。
?	選擇“添加計(jì)數(shù)器”。

現(xiàn)在，可以開(kāi)始選擇這些對(duì)象和要監(jiān)視的計(jì)數(shù)器了。

ASP.NET 應(yīng)用程序性能計(jì)數(shù)器

有關(guān) ASP.NET 應(yīng)用程序性能計(jì)數(shù)器的大部分信息最近已被合并到一個(gè)題為“改善 .NET 應(yīng)用程序的性能和伸縮性”的綜合文檔中。下表描述了一些可用于監(jiān)視和優(yōu)化 ASP.NET 應(yīng)用程序（包括 Reporting Services）性能的重要計(jì)數(shù)器。

性能對(duì)象	計(jì)數(shù)器	實(shí)例	描述
Processor（處理器）	% Processor Time（處理器時(shí)間百分比）	__Total	“% Processor Time”監(jiān)視運(yùn)行 Web 服務(wù)器的計(jì)算機(jī)的 CPU 利用率。低 CPU 利用率或者無(wú)法最大化 CPU 利用率（無(wú)論客戶端負(fù)載為多少）都表明 Web 應(yīng)用程序中存在對(duì)資源的爭(zhēng)用或鎖定。
Process（進(jìn)程）	% Processor Time（處理器時(shí)間百分比）	aspnet_wp 或 w3wp（具體情況視 IIS 版本而定）	由 ASP.NET 工作進(jìn)程所使用的處理器時(shí)間所占的百分比。在將標(biāo)準(zhǔn)負(fù)載情況下的性能與先前捕獲的基準(zhǔn)進(jìn)行對(duì)比時(shí)，如果此計(jì)數(shù)器的值出現(xiàn)下降，則說(shuō)明降低了對(duì)處理器的需求，因此也提高了伸縮性。
Process（進(jìn)程）	Working Set（工作集）	aspnet_wp 或 w3wp（具體情況視 IIS 版本而定）	由 ASP.NET 主動(dòng)使用的內(nèi)存數(shù)量。雖然應(yīng)用程序開(kāi)發(fā)人員對(duì)應(yīng)用程序使用的內(nèi)存數(shù)量擁有最大的控制權(quán)，但系統(tǒng)管理員也可通過(guò)調(diào)整會(huì)話的超時(shí)期限來(lái)顯著影響這一點(diǎn)。
Process（進(jìn)程）	Private Bytes（專(zhuān)有字節(jié)）	aspnet_wp 或 w3wp（具體情況視 IIS 版本而定）	Private Bytes 是當(dāng)前分配給該進(jìn)程且不能由其他進(jìn)程共享的內(nèi)存數(shù)量（以字節(jié)計(jì)）。不時(shí)出現(xiàn)的尖峰表明某些地方存在瓶頸，會(huì)導(dǎo)致工作進(jìn)程繼續(xù)持有不再需要的內(nèi)存。如果此計(jì) 數(shù)器突然下降為接近 0 的值，則可能表示 ASP.NET 應(yīng)用程序由于無(wú)法預(yù)料的問(wèn)題進(jìn)行了重啟。為了驗(yàn)證這一點(diǎn)，請(qǐng)監(jiān)視“ASP.NET Application Restarts”計(jì)數(shù)器。
ASP.NET Applications（ASP.NET 應(yīng)用程序）	Requests/ Sec（每秒的請(qǐng)求數(shù)）	__Total	允許您檢驗(yàn)請(qǐng)求的處理速度是否于發(fā)送速度相適應(yīng)。如果每秒請(qǐng)求數(shù)的數(shù)值低于每秒產(chǎn)生的請(qǐng)求數(shù)，則會(huì)出現(xiàn)排隊(duì)現(xiàn)象。這通常意味著已經(jīng)超過(guò)了最大請(qǐng)求速度。
ASP.NET Applications（ASP.NET 應(yīng)用程序）	Errors Total（總錯(cuò)誤數(shù)）	__Total	在 執(zhí)行 HTTP 請(qǐng)求期間發(fā)生的錯(cuò)誤總數(shù)。包括任何分析器、編譯或運(yùn)行時(shí)錯(cuò)誤。此計(jì)數(shù)器是“Errors During Compilation”（編譯錯(cuò)誤數(shù)）、“Errors During Preprocessing”（預(yù)處理錯(cuò)誤數(shù)）和“Errors During Execution”（執(zhí)行錯(cuò)誤數(shù)）計(jì)數(shù)器的總和。運(yùn)轉(zhuǎn)正常的 Web 服務(wù)器不應(yīng)產(chǎn)生任何錯(cuò)誤。如果錯(cuò)誤發(fā)生在 ASP.NET Web 應(yīng)用程序中，它們的存在可能會(huì)讓實(shí)際的吞吐量結(jié)果產(chǎn)生偏差。
ASP.NET	Request Execution Time（請(qǐng)求執(zhí)行時(shí)間）	?	顯示了呈現(xiàn)所請(qǐng)求頁(yè)面并將其傳送給用戶所需的時(shí)間（以毫秒計(jì)）。跟蹤此計(jì)數(shù)器通常要比跟蹤頁(yè)面呈現(xiàn)時(shí)間效果更好。此計(jì)數(shù)器可以更全面地衡量從開(kāi)始到結(jié)束的整個(gè)請(qǐng)求時(shí)間。在與基準(zhǔn)進(jìn)行對(duì)比時(shí)，如果此計(jì)數(shù)器的平均值較低，則說(shuō)明應(yīng)用程序的伸縮性和性能均得到了改善。
ASP.NET	Application Restarts（應(yīng)用程序重新啟動(dòng)）	?	應(yīng) 用程序在 Web 服務(wù)器生存期間發(fā)生重新啟動(dòng)的次數(shù)。每次發(fā)生 Application_OnEnd 事件時(shí)，應(yīng)用程序的重新啟動(dòng)次數(shù)都會(huì)增加。應(yīng)用程序進(jìn)行重新啟動(dòng)的原因可能是：更改了 Web.config 文件、更改了存儲(chǔ)在應(yīng)用程序的 bin 目錄下的程序集、或者 Web Forms 頁(yè)面中發(fā)生了太多的更改。如果此計(jì)數(shù)器的值出現(xiàn)意料之外的增加，說(shuō)明某些不可預(yù)知的問(wèn)題導(dǎo)致 Web 應(yīng)用程序被關(guān)閉。在這種情況下，應(yīng)該認(rèn)真調(diào)查問(wèn)題原因。
ASP.NET	Requests Queued（排隊(duì)的請(qǐng)求數(shù)）	?	在隊(duì)列中等待服務(wù)的請(qǐng)求數(shù)。如果此數(shù)字隨著客戶端負(fù)載的增加而呈現(xiàn)線性的增長(zhǎng)，則說(shuō)明 Web 服務(wù)器計(jì)算機(jī)已經(jīng)達(dá)到了它能夠處理的并發(fā)請(qǐng)求極限。此計(jì)數(shù)器的默認(rèn)最大值為 5,000。您可以在計(jì)算機(jī)的 Machine.config 文件中更改此設(shè)置。
ASP.NET	Worker Process Restarts（工作進(jìn)程重新啟動(dòng)）	?	工作進(jìn)程在服務(wù)器計(jì)算機(jī)上重新啟動(dòng)的次數(shù)。如果出現(xiàn)意料之外的故障或者被有意回收，則工作進(jìn)程會(huì)重新啟動(dòng)。如果此計(jì)數(shù)器的值出現(xiàn)意料之外的增加，應(yīng)認(rèn)真調(diào)查問(wèn)題原因。

除了上表中介紹的這些核心監(jiān)視要素之外，在您試圖診斷 ASP.NET 應(yīng)用程序具有的特定性能問(wèn)題時(shí)，下表中的性

轉(zhuǎn)載于:https://www.cnblogs.com/KevinXia/p/3670401.html

總結(jié)

以上是生活随笔為你收集整理的Reporting Services 的伸缩性和性能表现规划(转载)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。