Reporting Services 的伸缩性和性能表现规划(转载)
簡介
Microsoft? SQL Server? Reporting Services 是一個將集中管理的報告服務器具有的伸縮性和易管理性與基于 Web 和桌面的報告交付手段集于一身的報告平臺。Reporting Services 是微軟功能全面的商業智能平臺的重要組件。
對于許多組織，通過報告提供信息是日常業務操作的一種基本活動。所以，報告系統的性能表現必須確保一致和可預測。隨著報告負載的增加，組織必須能夠以一種可預期和具有成本效益的方式提高報告能力。
關于本文
本文旨在幫助客戶和合作伙伴確定如何面對日益增加的負載，以最佳方式規劃、優化和伸縮他們的報告服務實現架構。本白皮書討論了以下主題：
| ? | 不同硬件配置的性能表現和伸縮特性（如縱向伸縮和橫向伸縮） |
| ? | 報告緩存和文件系統存儲對性能的影響 |
| ? | 有關 Reporting Services 性能優化的最佳做法 |
| ? | 有關運行您自己的性能測試的建議 |
雖然本白皮書關注的目標是 Microsoft SQL Server 2005 Reporting Services，但文中提供的大多數信息也適用于該產品的早期版本。
前提條件
本白皮書并不打算事無巨細地包含有關 Reporting Services 的所有信息。如需獲得有關該產品的詳細信息，請參見產品文檔以及可通過以下地址獲得的其他在線資源：http://www.microsoft.com/sql/reporting/.
除 Reporting Services 之外，本文檔假設讀者已經熟悉以下主題：
| ? | Microsoft SQL Server |
| ? | Internet Information Services (IIS) |
| ? | Microsoft .NET Framework |
有關這些主題的信息可通過以下地址從 MSDN 網站上獲得：http://msdn.microsoft.com?
返回頁首概述
Reporting Services 是基于服務器的全面平臺，用于創建、管理和交付基于紙張的傳統報告和基于 Web 的互動式報告。在執行報告時，Reporting Services 執行以下基本工作：
| ? | 取得要報告的數據 |
| ? | 根據報告定義中的指令處理數據 |
| ? | 以特定格式呈現報告 |
Reporting Services 還執行支持報告處理的其他工作，例如管理和處理訂閱，管理和處理快照和緩存請求，以及提交報告管理請求。
Reporting Services 的工作負載主要來自于以下三種應用情境：
| ? | 在線用戶對已發布報告的互動式訪問 |
| ? | 根據預先計劃或由事件驅動，通過訂閱以電子郵件或文件共享方式交付報告 |
| ? | 由在線用戶動態創建和執行的特別報告 |
本白皮書集中討論第一種應用情境，即由在線用戶執行已發布報告。這是大多數客戶希望增強其伸縮能力的主要工作負載。
交 付訂閱報告的優點在于可以預先設定日程安排，因此為您賦予了控制在何時和何處執行處理過程的更強能力?；邮綀蟾鎰t更難于做出規劃，因為它很大程度上要取 決于報告的規模和復雜性、并發用戶的數量以及報告的呈現格式。在訪問互動式報告時，用戶還對系統響應速度抱有很高的期望。
利用 SQL Server 2005 Reporting Services，最終用戶可使用新的 Report Builder 工具，以交互方式創建和執行報告。創建特別報告為 Report Server 帶來的額外負擔很難進行量化，因為這要視用戶操作的內容及效率而定。特別報告的伸縮性將在本白皮書今后的版本中予以介紹。
本白皮書包含一些通用的性能指南，這些指南是微軟在針對不同配置創建和測試交互式報告負載的過程中總結而成的。但是，若要獲得能夠反映您自身環境的具體性能數字，需要您自己運行性能測試。本白皮書所提供圖形和結果的目的僅是幫助用戶了解不同配置具有的伸縮特性。
伸縮性和可靠性
系統伸縮性難以定義，因為它經常對不同的人具有不同的含義。之所以如此，是因為人們經常將伸縮性與可靠性放在一起進行討論。雖然可靠性是任何系統配置都不可忽視的重要考慮事項，但是它的存在是否會對實際的伸縮性造成影響并無法確定。
在 本文中，伸縮性被定義為：在不從根本上改變系統設計或架構的情況下，通過逐步增加系統資源讓系統支持更多工作負載的一種能力。理想情況下，隨著系統資源的 增加，系統處理工作負載的能力也應隨之成比例增加。雖然這聽起來很直觀，但是實現?°近乎線性?±的伸縮性通常十分困難。實際上，系統通常無法實現完美的 線性伸縮。這是由于部署在各種異類系統中的多個應用程序組件間必不可少的管理、協調和溝通工作會帶來的大量的開銷。
系統可靠性所基于的觀點 則與此稍有不同?？煽肯到y是一種在不出現故障的情況下對不斷增加的工作負載進行妥善處理的系統。此外，可靠系統不應隨著工作負載的增加而出現崩潰或運行中 止。相反，其性能只應出現緩慢的下降。但是，在壓力足夠大的情況下，任何系統都可能變得不可用。而可靠系統的獨特之處就在于它們能夠從這些事件中恢復。
對于為實施 Reporting Services 而進行的容量規劃，其成功關鍵便在于在工作過載和系統平滑處理增加的工作負載之間找到平衡，并籍此建立滿足伸縮性要求的可靠系統。
縱向伸縮和橫向伸縮
Reporting Services 的靈活設計使得用戶既可在單臺服務器也可在多臺服務器上部署其組件，具體情況則取決于用戶的需要和喜好。
開始時，Reporting Services 的用戶經常詢問應購買單臺的大型服務器（縱向伸縮）還是應購買多臺小型服務器（橫向伸縮）。本白皮書介紹了 Reporting Services 的伸縮特性，在解答用戶提出的這個問題的同時幫助他們做出明智決策。
縱向伸縮途徑使用一臺大型的對稱多處理器服務器提供更高的處理能力。與橫向伸縮相比，這種方法的優點在于它具有更為輕松的配置和管理體驗?？v向伸縮還是一種用于伸縮 SQL Server 關系型引擎和 Analysis Services 的方法。
橫向伸縮是 Reporting Services Enterprise Edition 支持的配置方式，也是大多數客戶考慮采用的伸縮方式。這主要是由于橫向伸縮：
| ? | 允許用戶根據需要逐步增加或撤除容量 |
| ? | 為增加和撤除容量提供了一種非常靈活、易于管理和價格可承受的方法。 |
| ? | 允許在多臺商用服務器上平衡大量工作負載 |
| ? | 提供了一定程度的固有容錯能力 |
如 果您決定使用橫向伸縮配置方式部署 Reporting Services，應當意識到需要在多臺 Report Servers 之間進行協調，讓它們都能夠訪問安裝在本地或遠程 SQL Server 關系型數據庫上的單個 Report Server 目錄。有關 Reporting Services 部署選項的更多信息，請參閱位于如下地址的在線文檔：http://www.microsoft.com/sql/reporting/ 和 http://technet.microsoft.com/sql.
Reporting Services 組件
為了全面理解伸縮性，首先需要理解 Reporting Services 的體系結構（如圖 1 所示）和它的各個組件。
圖 1：Reporting Services 的體系結構
查看大圖
Reporting Services 從邏輯上可劃分為三層（如表 1 所示）。
表 1
| 組件 | 功能 | ||||||||
| Report Server | 一個具備如下功能的 Web 服務：
Report Server 還包括一個負責日程計劃和批操作的 Windows 服務。本白皮書未討論該應用情境的伸縮性問題。 | ||||||||
| Report Server Catalog | 以下兩個 SQL Server 數據庫來自該目錄：
該目錄可與 Report Server 駐留在同一物理系統上，也可位于不同系統上（遠程目錄）。 | ||||||||
| 客戶端應用程序 | 客 戶端應用程序通過 SOAP Web 服務和 URL 請求訪問服務器。Report Management 工具和 Report Viewer 應用程序是包含在 Reporting Services 之中的客戶端應用程序。Microsoft? Visual Studio? 2005 為在客戶端系統中嵌入報告提供了 Report Viewer。Report Builder 是用于特別報告的報告制作工具。許多第三方軟件廠商還提供它們自己的客戶端應用程序。 |
伸縮指南
本部分內容介紹 Reporting Services 的基本配置選項，并描述它們對性能和伸縮性的影響。本部分內容的目標是幫助讀者找出滿足自身的性能和負載需要的有效 Reporting Services 配置，并且回答如下問題：
| ? | 您應該考慮在遠程計算機上承載目錄嗎？ |
| ? | 對 Report Server 進行縱向伸縮和增添其他 Report Server 這兩種方法哪一種更佳？ |
| ? | 對于配備四顆處理器的 Report Server，哪一種配置方式最佳？ |
雖然微軟對不同配置執行的測試均在施加特定報告負載的情況下得出了結果，但您的實際性能需求應視您的自身環境所特有的各項因素而定。這些因素包括：
| ? | 并發用戶的數量 |
| ? | 所產生報告的大小和復雜性 |
| ? | 按需生成報告還是通過訂閱生成報告 |
| ? | 實時生成報告還是緩存報告 |
后文中的測試結果僅用于確定各種不同配置的相對性能和伸縮特性。請注意，原始指標（例如每秒的頁面瀏覽量）與您的環境和應用情境不同。我們的重點在于這些指標隨著向環境分配或增添資源而取得的相對改善。本白皮書后面的章節為您創建自己的性能基準提供了操作指南。
本地配置和遠程配置
微軟測試了兩種本地配置，在同一臺服務器上運行 Report Server 及其目錄。
查看大圖
在 本地配置方式中，SQL Server 關系型數據庫將與 Report Server 爭奪可用的計算機資源。如果有足夠的資源，將不會出現任何問題。您可能應考慮將最大數量的內存和最多數量的處理器設置為由 SQL Server 數據庫引擎使用，以減少它與 Reporting Services 間的資源爭用。有關更多信息，請參見附錄 A。用戶還可選擇圖 2 中展示的配置，因為它僅需一份 SQL Server 許可證。
作為對比，圖 3 中展示的遠程目錄實現方式需要將 Reporting Services 組件分布在兩臺物理服務器上。第一臺服務器承載 Report Server 引擎，而第二臺則以遠程方式承載目錄。
圖 3：遠程目錄實現方式
查看大圖
遠程配置方式消除了 Report Server 和承載目錄的 SQL Server 之間對計算機資源的爭奪。但是，您必須在 Report Server 和目錄服務器間提供足夠的網絡帶寬。
縱向伸縮和橫向伸縮
在將目錄分隔到其他系統中后，可以選擇通過增加處理器來對 Report Server 執行縱向伸縮，也可以通過增加計算機來執行橫向伸縮。圖 4 描述了使用多臺 Report Server 訪問單個目錄的橫向伸縮配置。
?
圖 4：使用多臺 Report Server 訪問單個目錄的橫向伸縮配置方式
查看大圖
通 常，橫向伸縮配置方式使用一臺遠程關系型數據庫服務器，該服務器用于承載目錄，并且與所有 Report Server 節點均分開布置。雖然可將目錄放在其中一個 Report Server 節點上，但我們不推薦采用這種配置方式，因為數據庫服務器將與 Report Server 爭奪資源。
4 顆處理器的橫向伸縮配置方式使用 2 臺 Report Server（每臺服務器配備 2 顆處理器）訪問遠程目錄。8 處理器的橫向伸縮配置方式使用 4 臺配備 2 顆處理器的 Report Server。因此，橫向伸縮配置不僅處理器數量會成倍增加，而且內存和網絡帶寬也同樣會成倍增加。
本地目錄和遠程目錄性能比較
在伸縮性規劃中需要首先決定的事情之一便是：是在與 Report Server 相同的系統上承載 Report Server 目錄（本地模式），還是分開單獨承載目錄（遠程模式）。
在本地模式中，一臺物理計算機同時承載 Report Server 和 Report Server 目錄（一個 SQL Server 實例）。該目錄獨立于報告數據的源數據庫，此數據庫通常位于其他服務器上。
單臺計算機的設置方式是最簡單的實現方式，從許可證的觀點看，也是較為便宜的配置方式，但是它仍然具有幾個缺點。最重要的是，將目錄移動到遠程服務器是朝橫向伸縮配置方式邁出的第一步。本文的以后部分將對此進行討論。
在回答向本地實現方式添加處理器和分離出目錄這兩種方式哪一種較佳這個問題時，我們使用如下系統配置進行了測試：
| ? | 配備 2 顆處理器的 Report Server，本地目錄（2 處理器） |
| ? | 配備 2 顆處理器的 Report Server，遠程目錄（遠程 2 顆處理器） |
| ? | 配備 4 顆處理器的 Report Server, 本地目錄（4 處理器） |
| ? | 配備 4 顆處理器的 Report Server，遠程目錄（遠程 4 顆處理器） |
測試結果揭示了幾個很有意思的事實，為究竟應首先縱向伸縮處理器還是應首先分隔報告目錄這個問題提供了答案。
| ? | 對于使用 2 顆處理器的系統，本地和遠程實現方式在輕負載情況下的性能表現大致相同。 |
| ? | 相比于 2 顆處理器的本地系統，4 顆處理器的本地系統在每秒處理的請求數這一指標上具有較好的表現，但是并不像 4 顆處理器的遠程系統那樣實現了性能翻番。 |
表 2 展示了四種配置方式的峰值處理能力（即性能保持在等于 30 秒的閥值之上時能夠處理的最大會話數量）的比較結果。
表 2
| ? | 每秒的平均請求數 | 峰值會話數 |
| 2 處理器（本地） | 基準 | 基準 |
| 2 處理器（遠程） | -10% | 基準 |
| 4 處理器（本地） | 53% | 17% |
| 4 處理器（遠程） | 100% | 117% |
從 2 處理器的本地實現方式切換到 2 處理器的遠程實現方式本身對服務器能夠支持的峰值會話數量不會產生實質性的影響。在吞吐量方面會有一點下降，因為通過網絡傳輸數據會產生一定的開銷。
在更高工作負載的情況下，成倍增加本地目錄實現方式上的處理器數量（從 2 顆處理器的本地實現到 4 顆處理器的本地實現）實際并不能將可用資源提高兩倍。它只能適度提高峰值會話數量，并在每秒處理的請求數方面有 53% 的改進。
但是，在遠程目錄實現方式中，成倍增加處理器（從 2 顆到 4 顆）可提供線性的伸縮能力。在 4 顆處理器的情況下，峰值請求數量的成倍增加還有甚于峰值會話數量的成倍增加。
關鍵點
| ? | 如果您正在運行 2 顆處理器的本地系統，將目錄分隔到其他服務器上對系統整體性能帶來的提升最少。 |
| ? | 分隔目錄會為管理和監視這樣的工作帶來便利，因為系統不再需要在 Report Server 和數據庫進程間分配資源。 |
| ? | 如果您正在運行 4 顆處理器的本地系統，將目錄分隔到其他服務器會顯著提升系統的性能。 |
| ? | 對于打算提高伸縮性的系統，遠程目錄實現方式是朝橫向伸縮配置方式邁出的第一步。 |
縱向伸縮
本 部分內容討論在遠程目錄配置方式中通過增加處理器數量（縱向伸縮）來提升系統的容量和性能。在本例中，縱向伸縮是從 2 顆處理器的遠程系統切換為 4 顆處理器的遠程系統。在以下測試中，當響應時間超過預先定義的 30 秒閥值之后便視為達到了極限，這個時間對于大多數用戶來說似乎都是無法忍受的。
表 3
| ? | 每秒的平均請求數 | 最大會話數量 | 每分鐘的頁面瀏覽量 |
| 2 處理器（遠程） | 10.71（基準） | 600（基準） | 604（基準） |
| 4 處理器（遠程） | 23.91 (123%) | 1300 (117%) | 1327 (120%) |
每秒的平均請求數
在高用戶負載情況下，4 處理器系統每秒可以處理的請求數顯然遠遠大于 2 顆處理器的遠程系統。在遠程目錄實現方式中，成倍增加處理器的數量可以使得每秒的平均請求數稍稍高于原先的兩倍。
最大會話數量
4 處理器的遠程配置方式可以支持的最大會話數量超過了 2 顆處理器的遠程實現方式所支持最大會話數量的 2 倍。
每分鐘頁面瀏覽量
每分鐘頁面瀏覽量這一指標考察了頁面生成能力。在遠程目錄實現方式中，通過將處理器數量從 2 成倍增加到 4，可以在高負載情況下將頁面瀏覽量提升為原先的 120%。
關鍵點
| ? | 在將報告目錄分隔到其他系統后，將處理器數量從 2 成倍增加到 4 基本上可將 Reporting Services 的處理能力成倍增加，同時不會降低系統的響應速度。 |
| ? | 僅針對將處理器數量從 2 增加到 4 的情況進行了測試。以后的測試將考察使用更多處理器來優化系統的情況。 |
橫向伸縮
本部分內容考察橫向伸縮配置對容量和性能的影響。在微軟進行的測試中，Report Servers 忠實地復制了 2 顆處理器遠程目錄實現方式中的服務器配置。因此，橫向伸縮服務器的數量加倍，而所有系統資源（內存、存儲和網卡）的數量則翻了四倍。
如果將 2 顆處理器的遠程實現方式的系統處理能力與 4 顆或 8 顆處理器的橫向伸縮配置進行對比，使用橫向伸縮配置的系統可以提供近乎線性的伸縮能力。下表總結了 4 顆和 8 顆處理器的橫向伸縮配置相對于作為基準的 2 顆處理器遠程系統在各方面取得的進步。
表 4
| ? | 峰值頁面瀏覽量/小時 | 最大并發會話數 (11/14/2005) |
| 2 處理器（遠程） | 10.71（基準） | 600（基準） |
| 2 X 2 處理器（遠程） | 23.87 (210%) | 1300 (216%) |
| 4 X 2 處理器（遠程） | 45.18 (378%) | 2500 (416%) |
比較每秒的峰值平均請求數以及支持的峰值會話數，2 X 2 處理器的橫向伸縮配置方式提供了優于 2 顆處理器遠程實現方式的線性伸縮能力。
如果僅比較各種橫向伸縮實現，從 2 X 2 處理器的橫向伸縮轉移到 4 X 2 處理器的橫向伸縮不會提供真正線性的伸縮能力。但是，它也可顯著提升處理能力，每秒處理的請求數增加了 89%，而支持的峰值會話數則提高了 92%。
關鍵點
| ? | 橫向伸縮途徑是一條極具成本效益的途徑，可在無需大量硬件投入的情況下極大提升系統容量。 |
| ? | 如果您預計對 Reporting Services 的需求將持續增加，那么橫向伸縮是根據需要增加更多容量的一種靈活方法。 |
縱向伸縮和橫向伸縮比較
縱向伸縮和橫向伸縮應用方案的直接比較可以通過比較 4 處理器的遠程目錄和 4 處理器的橫向伸縮的容量來進行。在第一種情況下，四顆處理器位于同一臺 Report Server 上，而橫向伸縮則使用兩臺配備了 2 顆處理器的 Report Servers。
測試結果表明，兩種實現方式之間的差別有限，在每秒的平均請求數和支持的峰值會話數方面它們都旗鼓相當。
橫向伸縮在所有節點上總共使用了 8 GB 內存，而 4 處理器的遠程系統則使用了 4 GB 內存。
在 同樣會話數的情況下，4 處理器系統的系統響應時間方面也不落下風。4 處理器的橫向伸縮配置在響應時間方面稍占優勢。由于在 Reporting Services 部署中，我們對 ASP.NET 應用程序進行了仔細調較以充分利用橫向伸縮配置中價格便宜的硬件設備，這個結果在我們的預料之中。
關鍵點
如 果您已經擁有一個 2 處理器的遠程目錄系統，并且必須將其處理能力翻番，將該系統縱向伸縮到 4 處理器的 Report Server 或橫向伸縮為兩臺 Report Servers 都是可行的。雖然轉移到橫向伸縮配置要求您轉移到 Reporting Services Enterprise Edition，但在獲得能力提升之外還可獲得其他眾多益處。這些益處包括：
| ? | 處理器數目較少的服務器價格與大型的 SMP 服務器相比較為低廉。 |
| ? | 其他計算機可以利用專用的內存地址空間，而無需轉移到 64 位系統。 |
| ? | 利用增加服務器而不是升級現有服務器來提升能力的做法具有更短的停機時間。 |
| ? | 使用多臺報告服務器的做法具有更出色的可用性，如果某臺服務器發生故障，整個系統仍然可以繼續響應請求。 |
| ? | 可以輕松地將橫向伸縮擴展到 6、8 或 10 顆處理器。通常，在伸縮至 8 顆處理器后，SMP 服務器的性能增長將后繼乏力。 |
使用 64 位處理器
SQL Server 2005 Reporting Services 支持 64 位處理器，包括 Intel Itanium2 處理器以及 AMD 和 Intel 的 x64 架構。在 x64 系統上，Reporting Services 既可運行于本機 64 位模式，也可以運行于 32 位的 Windows on Windows (WOW) 子系統上。
通常，在具有相同速度的處理器上運行 64 位系統不會提高報告的吞吐量。相反，從中獲得主要好處是用戶可以查看和導出大型報告的輸出結果。當工作負載提高時，可以在 64 位計算機上獲得更大吞吐能力，因為對內存的爭用減少了，而且垃圾回收操作的頻率也顯著降低。在撰寫本白皮書之時，微軟無法全面測試這些平臺，但是計劃在本 文檔的未來版本中增加相關測試結果。
返回頁首報告緩存和存儲
影響 Reporting Services 實現方式的性能和容量的一大因素便是：用戶是通過從源系統中取得數據來實時生成報告，還是使用緩存或快照數據生成報告。本節內容介紹了一些選項以及這些選項對性能造成的潛在影響。
緩存實例
Report Server 有兩級緩存：
| 1. | 當 Report Server 生成報告時，它從 Report Server 目錄中取得報告定義并從數據源獲取報告數據。然后，它創建一份臨時報告格式，該報告保存在會話緩存中并寫入 ReportServerTempDB 數據庫。它使用該版本（緩存實例）創建和呈現最終的報告。 對于完全“實時”報告，它會對每份報告重復此過程。但是，也可以將對已處理過的報告的后續請求定向到緩存實例。這樣可顯著縮短取得數據和創建報告所需的時間。 |
| 2. | Report Server 還會嘗試對內存中或文件系統的臨時目錄下的緩存（或快照）報告的輸出格式進行緩存。如果請求的結果在輸出緩存中找到，便可以同時繞過處理和呈現步驟，因此 可實現非常優異的性能。有關如何確定所使用緩存的類型的更多信息，請參見有關性能計數器的附錄 B。 |
緩存最終會過期，并因此導致 Report Server 收集新鮮的數據?？筛鶕A定義的時間間隔、日程安排（特定于報告或共享）或強制過期來控制緩存過期時間。
緩存報告對存儲區會產生影響，雖然 SQL Server 2005 Reporting Services 以很緊湊的格式保存數據并且對數據進行了壓縮。在確定所要維護的緩存或快照映像的數量時，請考慮以下因素：
| ? | 創建緩存實例時應用的查詢參數。如果您需要一份帶有不同查詢參數的報告，Reporting Services 將生成另外一個緩存實例。 |
| ? | 查詢（過濾器）中未使用的報告參數可以用來創建不同于緩存實例的報告版本。 |
報告快照
快照指的是以更加持久的方式保存的同一份臨時報告格式。例如，快照可以保存在 Report Server 目錄中，而不是保存到 ReportServerTempDB 數據庫。此外，目錄還可保有作為報告歷史的多個臨時版本，因此允許用戶在這些版本中做出選擇。
SQL Server 2005 Reporting Services 自動對目錄中的快照進行壓縮。也可以將快照映像保存到本地文件系統中。
以下章節重點介紹了使用緩存實例、壓縮快照以及文件系統存儲三種方式對性能的映像。
緩存實例
提高 Reporting Services 部署的容量和伸縮能力的一種方法便是：避免使用實時數據來執行報告。如果能達到相同的目的，那么可以轉而使用緩存數據來執行報告。
圖 5 中的圖形顯示了檢索、處理和呈現一個包含 150 行數據的報告所花費的時間（包括針對實時數據和緩存數據的兩種結果）。
?
圖 5：150-K 行的簡單報告的時間計算結果
查看大圖
綜合來看，這些數字表明：對 Reporting Services 使用實時數據時，需要的時間是使用緩存數據的 2.61 倍。返回大量實時數據的報告所需的資源遠遠超出使用緩存數據的報告。
在系統使用高峰的幾個小時內，要求最終用戶避免運行實時報告是不切實際的。用戶經常不會意識到運行這樣的報告會對系統性能和其他系統用戶造成何種影響。為了提高系統容量和響應速度，一些可以考慮傳達給用戶的“好公民”做法包括：
| ? | 盡可能避免讓報告檢索或執行大量實時數據。轉而使用緩存數據。 |
| ? | 如果無法完全避免使用實時數據，至少試著限制這種報告的運行數量，尤其是在高峰時段。 |
| ? | 如果可以使用緩存數據生成報告，可以將這些報告設定為在非高峰時段刷新緩存，以避免影響其他用戶。 |
經過壓縮的快照存儲
在 SQL Server 2005 Reporting Services 中，管理員們可以指定快照數據的存儲位置和存儲方式。
使用快照能夠顯著改善報告性能，但是會占用數據庫的存儲空間。為了在存儲空間和性能之間求得平衡，Reporting Services 提供了一個由系統屬性控制的壓縮選項。默認設置是對快照數據和報告定義進行壓縮。也可以關閉壓縮功能。
例如，在一個 20,000 行的報告中，SQL 的快照壓縮功能可以將快照大小降低 20%。更小的體積不僅意味著可節省 Report Server 目錄中的大量存儲空間，而且還能極大降低 Report Server 和目錄間的網絡流量。
文件系統存儲
用于存儲快照的另一個選項是：使用文件系統 (FS) 存儲。此設置不受 SQL 壓縮選項的影響，因為數據保存在文件系統中。
FS 快照存儲非常適用于 Reporting Services 的遠程目錄和橫向伸縮部署方式。如果啟用了 FS 存儲，快照數據可以存放在 Report Server 的本地文件系統中。這使得 Report Server 可以避免為支持會話和報告請求而往返于目錄。
可以通過更改 RSReportServer.config 文件中的 WebServiceUseFileShareStorage 鍵值來控制 FS 的使用。若要開啟 FS，請根據如下所示更改該值：
<Add Key="WebServiceUseFileShareStorage" Value="true" />若要關閉 FS，只需將該鍵值設置回“false”。
注意：默認情況下，FS 將快照數據保存到文件系統的 C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.instanceReporting ServicesRSTempFiles 目錄下。CleanupCycleMinutes，位于 RSReportServer.config 文件中，控制未使用的 FS 數據的刪除頻率。對于操作頻繁的系統，在設置該文件夾的存儲空間需求時應十分謹慎，以免超出了可用的存儲空間限制。
如 果 Report Server 使用本地目錄而不是遠程目錄，那么它不會利用文件系統存儲?？煺諗祿呀洷４嬖诒镜氐?SQL Server 關系型數據庫中，而該數據庫則針對數據的存儲和檢索進行了充分優化。如果配置本地目錄系統以使其使用文件系統存儲，會造成存儲空間和快照管理出現不必要的 冗余。
壓縮和文件系統存儲的影響
微軟已經在 4 顆處理器的遠程系統上測試了壓縮和 FS 快照存儲對性能的影響。兩種技術都能提高系統在重負載情況下的處理能力。雖然壓縮會加重處理器的負擔，但它也降低了報告服務器和目錄之間的網絡流量。
表 5
| ? | 每秒的平均請求數（與基準數據的比值） | 每小時的頁面瀏覽量（與基準數據的比值） | 峰值會話數（與基準數據的比值） |
| 未壓縮 | 基準 | 基準 | 基準 |
| SQL 壓縮 | 基準 | 109% | 基準 |
| 文件系統存儲 | 126% | 129% | 113% |
文件系統存儲允許您支持更多數量的用戶會話，同時不會增加系統的響應時間。顯而易見，FS 設置具有最佳的伸縮性和處理能力。在測試 4 處理器的遠程目錄系統時，微軟通過開啟快照數據的文件系統存儲，將能夠支持的并發用戶會話數量提高了 13%。
關鍵點
| ? | 通過使用更多緩存實例和快照來代替實時報告，可以切實有效地提高現有系統的容量。 |
| ? | 對于大容量報告環境，使用文件系統快照可為橫向伸縮的遠程服務器實現方式提供盡可能高的處理能力和盡可能快的響應速度。 |
性能優化最佳實踐
本部分內容總結了容量規劃和性能優化的指導原則和最佳實踐。
選擇一種配置
通過閱讀縱向伸縮和橫向伸縮指南，各種系統配置的報告能力各不相同這一點變得愈加清晰了。
最 基本的配置方式是使用本地目錄的 2 處理器 Report Server。而最高端的配置是橫向伸縮配置，它具有強大的伸縮能力和優異的性能表現。雖然本白皮書中的測試僅僅討論了使用遠程目錄的四臺配備 2 顆處理器的 Report Server 的橫向伸縮配置，但是使用更大型的橫向伸縮配置也很容易。
在這兩種極端之間，您可以選擇遠程承載目錄，向本地或遠程實現方式添加處理器，或者以“Web 園”的方式將處理能力分配給單個系統中的多個處理器。
在為環境選擇正確的配置方式時，首先需要確定您對性能的特定要求。以下是可以使用的一些簡單指南：
| ? | 如果您的系統可以容納更多內存，請添加這些內存。這是因為內存占用是您可能遇到的第一個瓶頸。 |
| ? | 如果您擔心伸縮性并且運行一個本地目錄系統，要做的第一件事情就是在單獨的服務器上承載報告目錄。只有將目錄分隔出去才能通過增加處理器而顯著提高性能和負載方面的伸縮性。 |
| ? | 對于 4 顆處理器以下的系統，縱向伸縮和橫向伸縮都是不錯的方法。超過這個數字之后，橫向伸縮可能是最安全和最靈活的伸縮途徑。但是，我們并沒有對大型的 SMP 系統進行測試。 |
橫向伸縮配置方式中的橫向伸縮讓您能夠避免某些過程——例如設計特別報告和預先計劃的報告操作——干擾交互式報告的運行。例如：
| ? | 拿出一臺特定的 Report Server 作為所有 Report Builder 請求的前端，使用其余 Report Servers 處理交互式報告。 |
| ? | 拿出一臺或多臺 Report Servers 用于定期訂閱或由事件驅動的報告生成工作。 |
通用性能優化技巧
因 為 Report Server 目錄承載在 SQL Server 上，如果懷疑數據庫存在性能問題，可以應用針對 SQL Server 數據庫服務器的性能優化而提出的建議。這可能涉及從中獲取構建報告所需數據的源數據庫，也可能涉及用于支持所有報告服務實現的目錄數據庫。可以通過以下地 址找到有關 SQL Server 優化的詳細信息：http://www.microsoft.com/technet/ ，SQL Server 聯機圖書的“數據層：一條數據庫優化途徑”和 的“性能評估”章節也提供了相關優化信息。
以下是一些通用的性能優化技巧，在優化 Reporting Services 時請務必謹記在心：
| ? | 優 化您的報告查詢。通常，大部分報告執行時間都用來執行查詢和取得結果。如果您正在使用 SQL Server，諸如 Query Analyzer 和 Profiler 這樣的工具可幫助您優化查詢。此外，Database Tuning Advisor 也可為數據庫建議更好的索引方式。您還應該考慮使用 Analysis Services 提高性能。 |
| ? | 如果您在報告中不需要某些數據，請不要取得這些數據。使用數據庫操作（如篩選、分組和匯集）可減少報告處理的數據量并因此提高性能。 |
| ? | 讓報告的大小和復雜性保持適度。很少有用戶真的希望查看 1000 頁的報告。如果您發現需要處理大型報告，請想辦法將它們分解為較小的數據塊。 |
| ? | 如 果在單用戶的情況下性能也很糟糕，請檢查 ASP.NET 類別下的 Application Restarts 計數器。已知某些防病毒軟件會“修改”配置文件，并因此導致 Application Domain 在 Report Server Web 服務中頻繁重新啟動。有關更多信息，請在 http://support.microsoft.com/ 上搜索有關防病毒和 ASP.NET 的文章。 |
| ? | 如果在停止活動一段時間后首次訪問 Web 服務時性能緩慢，請在 IIS Manager 的 Application 的 Performance 選項卡上禁用空閑時間超時。 |
| ? | 盡可能使用緩存/快照數據執行報告（與實時數據相比而言）。 |
| ? | 將不重要的后臺處理限制到非高峰時間段執行，以避免與在線用戶爭奪資源。 |
| ? | 如果您的報告服務器擁有 4GB 內存，請記住在 C:boot.ini 中設置 /3GB 開關，以便應用程序能夠使用這些內存。 |
| ? | 如果在用戶使用系統時執行諸如清理 Reporting Services 中的會話這樣的維護管理工作，代價將十分昂貴。有關如何調整 RSReportServer.config 中的 CleanupCycleMinutes 時間間隔的說明，請參見附錄 A. |
| ? | 在多個數據文件上創建 Report Server 目錄?？梢詫祿腿罩痉旁诓煌奈锢泶疟P上來實現這個目的。具體做法請參見附錄 A. |
使用 Web 園
在 Microsoft? Windows? 2003 Server 上，可以通過配置“最大工作進程數”(Maximum Number of Worker Processes） 設置來提高伸縮性。
為 了找到該 Internet 信息服務 (IIS) 設置，請打開 IIS Manager 工具并查看分配給每個 Reporting Services 虛擬目錄 (vdir) 的應用程序池的屬性。默認情況下，這些屬性名為 Reports 和 ReportServer。您首先必須通過右擊 vdir 并選擇屬性選項來確定分配給每個 vdir 的應用程序池。分配的應用程序池將出現在“虛擬目錄”選項卡的底部。
在確定了正在使用的應用程序池之后，下一步便是打開所分配應用程序池的 屬性。也可以通過 IIS Manager 訪問該屬性。接著，找到“最大工作進程數”設置。通過右擊分配的應用程序池，選擇屬性選項并查看“性能”選項卡，可找到該設置。“最大工作進程數”設置出 現在“性能”選項卡的底部。
在配備 2 顆處理器和 4 顆處理器的系統上，提高工作進程的最大數量對系統容量和穩定性具有積極的影響。具體來說，在配備 4 顆處理器的系統上，將工作進程的最大數目從 1 更改為 4 可使 Report Processor 在性能出現下降之前處理更多的并發會話負載。更改該設置對配備 2 顆處理器的遠程系統的影響小于配備 4 顆處理器的遠程系統。
如果您的 Reporting Services 所運行的系統配備的處理器數量多于 4 顆，32 位尋址能力可能無法提供足夠的內存供多于 4 顆的處理器使用。您應執行更多測試來確認這些結果。
返回頁首其他工作負載的優化
雖然本白皮書主要關注交互式工作負載，但以下部分也提供了有關預定報告和特別報告負載的提示和技巧。未來版本的白皮書也將提供針對這些應用情境的附加指南。
預定報告的交付性能
預 定報告或訂閱報告按照預先計劃的時間運行，因此接受您的控制。如果 Reporting Services 環境提供了預定報告和按需報告，可將訂閱報告的處理工作隔離到一臺單獨的 Report Server 上。然后，可像其他 Report Server 一樣訪問同一個目錄，但是它并不處理交互式請求。這樣，訂閱報告的處理工作不會對按需報告的處理過程造成影響。
與交互式負載類似，預定操作的伸縮性也可以借助橫向伸縮配置而得到提高。所有后臺操作都放在目錄數據庫的一個隊列中，與之連接的每臺服務器都從中取出一個作業進行處理。
特別報告的性能
SQL Server 2005 Reporting Services 提供了一個特別報告工具，允許企業用戶以交互方式創建他們自己的報告。Report Builder 包括一個業務查詢模型，用戶無需深入了解底層數據源即可構造出報告。
在使用 Report Builder 時存在一個風險，即企業用戶在構造和運行復雜的資源密集型報告時會占用大量資源，這不僅會影響 Report Server，而且還會影響到源系統。
如果您希望廣泛使用 Report Builder，可以采取某些步驟保護整體系統性能不受損害。例如：
| ? | 將 Report Builder 會話隔離到一臺專用的 Report Server 上，防止意料之外的負載對其他用戶的交互式報告處理造成影響。 |
| ? | 不 要讓 Report Builder 會話直接與生產環境中的 OLTP 系統進行聯系。相反，應將它們導向生產型數據源的副本。根據所需延遲時間的不同，可以使用數據庫鏡像和復制這樣的技術來構建副本，或者使用 Integration Services 創建數據集市。通過這種方式，可避免不受控制的報告構建活動對生產系統產生負面影響。 |
運行您自己的性能測試
雖 然，模擬真實的負載條件不是一件輕松的工作，但我們強烈建議花時間這樣做。許多系統在投入生產環境后遭遇到性能問題，其原因均在于沒有在具體實施之前執行 足夠的壓力測試。正確的容量規劃和足以支持生產負載的充足服務器是在系統投入實際運行前避免各種主要問題的最佳方法。至少，您的部署計劃中應包括以下兩項 工作：
| ? | 模擬您的 Reporting Services 系統在投入生產環境后可能遇到的有代表性的負載。 |
| ? | 在與計劃中的生產環境基本相同的環境下執行測試。 |
通 過執行上述兩項工作并記錄在“分析指標”一節中討論的指標，可以在規劃部署時建立真實的性能基準。這樣的基準在將來檢驗應用程序、配置或硬件的更改效果時 十分有用。當使用某個已建立的基準時，可以通過重新運行相同的測試來驗證擬議的更改是否會對性能造成負面影響。在任何時候，只要對系統進行了大的更改，都 應重新建立性能基準。
微軟及第三方廠商提供了眾多壓力測試工具，可使用它們建立性能基準。Microsoft? Visual Studio? 2005 Team Test Edition 包括了用于執行網站負載測試的工具。更多相關信息，請訪問：http://msdn.microsoft.com/.
本白皮書的附錄介紹了大量的性能計數器，幫助您順利執行測試。
性能因素
在確定您的性能需求時，首先必須理解您對工作負載的需要。有些用戶使用 Reporting Services 并通過企業門戶提供按需報告，而有些用戶則需要處理和提供預定報告。此外，有些用戶還支持使用 Report Builder 創建特別報告。
影響工作負載和性能的其他因素包括：
| ? | 同時提出報告請求的用戶的數量 同時活動的會話數量越多，消耗的計算機資源也就越多。 |
| ? | 報告定義的規模和復雜性 與處理行數很少的簡單報告相比，處理包含大量行的報告顯然需要更多資源。 |
| ? | 是使用緩存或快照數據執行報告，還是使用實時數據執行報告。 使用緩存/快照數據執行的報告占用的資源顯著少于使用實時數據的報告。此外，使用緩存報告可減少從中獲取數據的源系統承擔的負載 |
| ? | Reporting Services 從中獲取報告數據的源數據系統的性能 如果針對這些系統執行查詢時速度緩慢，則說明您的報告也將運行緩慢。 |
| ? | 呈現報告時請求的格式 PDF 或 Microsoft? Excel? 這樣的格式比 HTML 格式更加耗用資源。 |
| ? | 承載目錄的數據庫服務器的性能 與源數據系統類似，如果承載目錄的系統十分緩慢，那么報告的執行速度也將十分緩慢。 |
正在進行設計或需要由用戶進行配置的許多事項也會影響報告的性能。這包括：
| ? | Reporting Services 配置文件、IIS 以及 Microsoft? Windows 操作系統中的應用程序設置。 |
| ? | 支持報告應用程序的硬件配置和設計。 |
| ? | 諸如交付基礎結構這樣的外部因素，包括網絡容量、用于交付訂閱的電子郵件服務器的性能或者是文件共享的可用性和性能。 |
若要正確規劃任何 Reporting Services 部署的容量，首先需要理解您的工作負載具有的特性。您的工作負載可能隨時間發生變化，并且在每月、每周或每日的使用中發生波動，具體情況則取決于各種業務因素的影響。
分析指標
當您確定系統的性能基準時，應該依據有意義的指標來進行確定。微軟在其伸縮性測試中使用了如下指標：
| ? | Simultaneous Session（并發會話） |
| ? | Average Requests per Second（每秒的平均請求數） |
| ? | Median Response Time（中值響應時間） |
| ? | Total Page Views per Minute（每分鐘的總頁面瀏覽量） |
Simultaneous Session指標是確定其他指標的優秀變量。例如，可以從 100 個并發會話開始，并以每次后續運行增加 100 個的速度進行增長，以這種方式產生測試負載。
The Average Requests per Second?指標有助于您理解每個給定的系統配置能夠成功支持多少個并發的 Web 請求。只要系統沒有在特定負載下表現的難以為繼，每次系統測試都應該為收到的所有請求提供同樣的服務。
如 果以每秒的請求數相對于并發會話數繪制圖形，可以找到曲線的頂點，該頂點代表了系統能夠應付的“每秒平均請求數”的最大值。此圖形可幫助您了解每個系統能 夠支持的每秒請求數峰值和最大會話數。顯然，如果希望了解“每分鐘平均請求數”或“每小時平均請求數”，可以輕松地對“每秒平均請求數”進行外推。
“中值響應時間”（收到最后一個字節的時間，或者說 TTLB）是一個常見指標，用來了解 Reporting Services 需要花費多長的時間才能對報告請求做出響應。顯然，響應時間越低越好
“每分鐘的總頁面瀏覽量”可幫助我們了解每種系統配置能夠支持的報告執行數量以及后續的頁面瀏覽量。實際上，可以獲得有關頁面瀏覽量的更詳細信息。這些信息包括：
| ? | 初始報告請求 為了獲得此信息，可模擬發出初始請求以查看報告第一頁的用戶。初始請求通常比后續頁面瀏覽請求要花費更長的時間。 |
| ? | 后續頁面瀏覽 為了獲得此信息，可模擬請求查看報告的后續頁面的用戶。 |
| ? | 總頁面瀏覽量 這是所有初始報告請求 (Initial Report Request)的總和，再加上所有后續頁面瀏覽量 (Subsequent Page Views），這是一個綜合值，代表所執行頁面瀏覽請求的整體數量。 |
思考時間
在實際工作中，用戶在查看報告結果和提交查看其他頁或運行其他報告的后續請求之間通常有一段等待時間。
微軟在內部測試中選擇了一個在 25 - 35 秒之間的隨機思考時間。該思考時間應當是比較真實的，因為我們假定執行報告的典型用戶在瀏覽后續頁面之前都會花費一定的時間查看報告結果。
命名用戶總數和并發活動會話
命名用戶總數并不等同于主動向 Reporting Services 發出請求的并發會話的數量。在規劃您自己的部署時，請注意以下幾點：
| ? | 命名用戶總數代表了獲得授權和具有訪問 Report Server 的潛在能力的所有用戶的總和。 |
| ? | 命名用戶總數中只有一部分代表給定時間內系統上以交互形式開展工作的并發會話。 |
| ? | 因為存在思考時間，這其中只有一部分屬于在給定時間同時向 Report Server 發出請求的并發活動會話。 |
總結
Microsoft SQL Server Reporting Services 的設計目標是：滿足各種組織的需要，提供經濟、靈活的報告能力，優化企業生產力。
Reporting Services 構建在 .NET 平臺和 Windows Server 系統的基礎之上，其伸縮性和可靠性足以支持要求苛刻的企業環境。它具有模塊化的可擴展架構，以及開放的接口和 API，幾乎能夠集成到所有 IT 環境之中。通過這種方式，它有效地將人員與遍布企業各處的信息聯系在一起。
大多數情況下，增加計算機資源都能夠以近乎線性的方式提高 Reporting Services 部署的伸縮性。增加系統容量的第一個合乎邏輯的步驟是將 Report Server 目錄分隔到遠程服務器上。然后，必須決定是以縱向伸縮還是橫向伸縮的方式來提高 Reporting Services 的處理能力。微軟執行的測試表明，這兩種方式都十分有效。因此，您的選擇在很大程度取決于您的經濟能力和喜好。
無論最終選擇何種伸縮途徑，建立您自己的自定義基準都十分重要。這樣，您可以在更改配置后，監視系統的處理能力是有所提高還是有所下降。只有測試能夠反映您的特定用戶需求的工作負載，才能夠確定所做更改對系統造成的影響是積極的還是消極的。
微軟提供了幾個工具（請參見本白皮書中的介紹），幫助您測試和監視 Reporting Services 的性能表現。通過使用本白皮書提供的指導原則，您應該已經可以成功地對 Reporting Services 部署進行簡單的容量規劃，并有效地監視其后續操作。
返回頁首附錄 A：系統配置設置
當配置 Report Server 系統時，應該查看以下設置和選項以優化性能。在創建基準性能量度時，它們尤其顯得重要。
CleanupCycleMinutes
CleanupCycleMinutes 字段控制 Reporting Services 執行特定維護和管理任務（例如清理過期會話和孤立會話）的頻率。在繁忙時段執行這些任務的開銷可能非常之大。如果有可用的磁盤空間來在更長期限內存儲會話 數據，可提高 CleanupCycleMinutes 的值以降低維護管理工作的執行頻率。您肯定還希望增加時間，以免它在運行基準性能測試時運行。
CleanupCycleMinutes 字段位于 RSReportServer.config 文件中。默認情況下，該文件位于 C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.InstanceReporting ServicesReportServer。默認設置為 10.但是，微軟在自己的伸縮性測試中將其更改為 1200,以避免這些進程在測試運行過程中啟動。
MaxActiveReqForOneUser
默 認情況下，Reporting Services 會限制單個用戶可以同時運行的未完成 URL 和 Web 服務請求的數量，以避免遭受拒絕服務 (DOS) 攻擊。作為管理員，您可以提高此限制，讓每位用戶能夠同時打開更多請求。當到達此設置的上限后，Report Server 自動丟棄來自該用戶的后續請求。
此值也可以在 RSReportServer.config 文件中找到。默認設置為 20。但是，根據您的測試環境中不重復用戶的數量，您可能必須增加該值。
當 SQL Server 與 Report Server 位于同一臺計算機上時，設置內存配置的限額。
通 過讓 SQL Server “釘住”特定數量的內存，可以規定由 SQL Server 和 Report Server 分別使用的內存數量。為此，請將內存的最大和最小數量設置為計算機的物理內存的一部分。例如，如果計算機配備了 3 GB 內存并且所有 Windows 應用程序都可以使用這些內存，可以讓 SQL Server 僅使用 1 GB 內存，而讓 Reporting Services 使用剩余的內存。
ReportServerTempDB 分區
對 于伸縮性測試，微軟創建了一個經過分區的 ReportServerTempDB 數據庫，該數據庫包括 10 個不同的 1 GB 大小的文件以及 1 個 1 GB 大小的事務日志，以提高磁盤 I/O 操作的并行度。如果在工作負載中使用快照執行測試，ReportServer 數據庫的分區也會大有益處。所有 11 個文件都分配到單個 RAID 0+1 存儲設備上，以優化目錄讀寫操作的性能。下面是一個 T-SQL 腳本示例，簡單演示了如何實現上述目的。
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 返回頁首附錄 B：性能測量工具
本部分內容介紹可用于測量和監視 Reporting Services 性能的各種工具。
Windows 性能監視器工具
可 使用集成化性能工具監視用于監視 Reporting Services 的性能計數器。運行 Reporting Services 的所有 Microsoft? Windows? 操作系統都包括了該工具。監視 Reporting Services 系統的特定性能計數器讓您能夠：
| ? | 估計支持預期負載所需的系統要求。 |
| ? | 創建性能基準，以測量配置更改和應用程序升級造成的影響。 |
| ? | 監視存在負載情況下的應用程序性能，無論是真實負載還是模擬負載。 |
| ? | 驗證硬件升級是否按照預期對性能產生了積極的影響。 |
| ? | 驗證系統配置更改是否按照預期對性能產生了積極的影響。 |
如果需要在一臺計算機上監視多個 Report Server 實例，可以同時或單獨監視這些實例。選擇要包括的實例是計數器添加過程的一部分。有關使用 Windows 附帶的性能工具的更多信息，請參見微軟 Windows 產品文檔。
若要訪問性能工具
| ? | 從“開始”菜單上選擇“運行”。 |
| ? | 在“打開”文本框中輸入“perfmon”，然后單擊“確定”。 |
| ? | 在性能監視器工具中，在左側窗格里選擇 System Monitor 對象，然后右擊“性能”圖表。 |
| ? | 選擇“添加計數器”。 |
現在，可以開始選擇這些對象和要監視的計數器了。
ASP.NET 應用程序性能計數器
有關 ASP.NET 應用程序性能計數器的大部分信息最近已被合并到一個題為“改善 .NET 應用程序的性能和伸縮性”的綜合文檔中。下表描述了一些可用于監視和優化 ASP.NET 應用程序（包括 Reporting Services）性能的重要計數器。
| 性能對象 | 計數器 | 實例 | 描述 |
| Processor（處理器） | % Processor Time（處理器時間百分比） | __Total | “% Processor Time”監視運行 Web 服務器的計算機的 CPU 利用率。低 CPU 利用率或者無法最大化 CPU 利用率（無論客戶端負載為多少）都表明 Web 應用程序中存在對資源的爭用或鎖定。 |
| Process（進程） | % Processor Time（處理器時間百分比） | aspnet_wp 或 w3wp（具體情況視 IIS 版本而定） | 由 ASP.NET 工作進程所使用的處理器時間所占的百分比。在將標準負載情況下的性能與先前捕獲的基準進行對比時，如果此計數器的值出現下降，則說明降低了對處理器的需求，因此也提高了伸縮性。 |
| Process（進程） | Working Set（工作集） | aspnet_wp 或 w3wp（具體情況視 IIS 版本而定） | 由 ASP.NET 主動使用的內存數量。雖然應用程序開發人員對應用程序使用的內存數量擁有最大的控制權，但系統管理員也可通過調整會話的超時期限來顯著影響這一點。 |
| Process（進程） | Private Bytes（專有字節） | aspnet_wp 或 w3wp（具體情況視 IIS 版本而定） | Private Bytes 是當前分配給該進程且不能由其他進程共享的內存數量（以字節計）。不時出現的尖峰表明某些地方存在瓶頸，會導致工作進程繼續持有不再需要的內存。如果此計 數器突然下降為接近 0 的值，則可能表示 ASP.NET 應用程序由于無法預料的問題進行了重啟。為了驗證這一點，請監視“ASP.NET Application Restarts”計數器。 |
| ASP.NET Applications（ASP.NET 應用程序） | Requests/ Sec（每秒的請求數） | __Total | 允許您檢驗請求的處理速度是否于發送速度相適應。如果每秒請求數的數值低于每秒產生的請求數，則會出現排隊現象。這通常意味著已經超過了最大請求速度。 |
| ASP.NET Applications（ASP.NET 應用程序） | Errors Total（總錯誤數） | __Total | 在 執行 HTTP 請求期間發生的錯誤總數。包括任何分析器、編譯或運行時錯誤。此計數器是“Errors During Compilation”（編譯錯誤數）、“Errors During Preprocessing”（預處理錯誤數）和“Errors During Execution”（執行錯誤數）計數器的總和。運轉正常的 Web 服務器不應產生任何錯誤。如果錯誤發生在 ASP.NET Web 應用程序中，它們的存在可能會讓實際的吞吐量結果產生偏差。 |
| ASP.NET | Request Execution Time（請求執行時間） | ? | 顯示了呈現所請求頁面并將其傳送給用戶所需的時間（以毫秒計）。跟蹤此計數器通常要比跟蹤頁面呈現時間效果更好。此計數器可以更全面地衡量從開始到結束的整個請求時間。在與基準進行對比時，如果此計數器的平均值較低，則說明應用程序的伸縮性和性能均得到了改善。 |
| ASP.NET | Application Restarts（應用程序重新啟動） | ? | 應 用程序在 Web 服務器生存期間發生重新啟動的次數。每次發生 Application_OnEnd 事件時，應用程序的重新啟動次數都會增加。應用程序進行重新啟動的原因可能是：更改了 Web.config 文件、更改了存儲在應用程序的 bin 目錄下的程序集、或者 Web Forms 頁面中發生了太多的更改。如果此計數器的值出現意料之外的增加，說明某些不可預知的問題導致 Web 應用程序被關閉。在這種情況下，應該認真調查問題原因。 |
| ASP.NET | Requests Queued（排隊的請求數） | ? | 在隊列中等待服務的請求數。如果此數字隨著客戶端負載的增加而呈現線性的增長，則說明 Web 服務器計算機已經達到了它能夠處理的并發請求極限。此計數器的默認最大值為 5,000。您可以在計算機的 Machine.config 文件中更改此設置。 |
| ASP.NET | Worker Process Restarts（工作進程重新啟動） | ? | 工作進程在服務器計算機上重新啟動的次數。如果出現意料之外的故障或者被有意回收，則工作進程會重新啟動。如果此計數器的值出現意料之外的增加，應認真調查問題原因。 |
除了上表中介紹的這些核心監視要素之外，在您試圖診斷 ASP.NET 應用程序具有的特定性能問題時，下表中的性
轉載于:https://www.cnblogs.com/KevinXia/p/3670401.html
總結
以上是生活随笔為你收集整理的Reporting Services 的伸缩性和性能表现规划(转载)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Equivalent Strings
- 下一篇： vc中关于 directx的配置，和dx