SQL Server 2005延展性和效能的計劃（1）

　　本白皮書提供了關於不同報表格服務實現架構中延展性的相關內容。也提供了一些基於使用Microsoft SQL Server Reporting Services完成您自己的效能測試的指導方針、建議和提示。

　　簡介

　　Microsoft® SQL Server™ Reporting Services是一個報表平台，包括可擴充和可管理的中央管理報表伺服器和可擴充的基於Web、案頭的報表交付。報表格服務是微軟綜合商業智慧平台的重要組成部分。對於許多組織，通過報表來交付資訊是一個非常重要的日常商務環節。因此，報表效能必須是一致的、可預見的。隨著報表資料的增加，組織必須能夠增加報表能力，以一種可預見的、成本低廉的方式。

　　關於該文檔

　　該文檔主要用來協助客戶和夥伴，在資料量增加的情況下，如何最好的計劃、最佳化和擴充他們的報表格服務執行。以下是本文的主要內容：

　　◆不同硬體設定的效能和擴充性，如scaling out 和scaling in

　　◆報表緩衝和檔案系統儲存對效能的影響

　　◆最佳化報表格服務的最佳實務

　　◆進行效能測試的建議

　　儘管該文章是寫Microsoft SQL Server 2005 Reporting Services，但是大多數的資訊對於早期的版本也同樣適用。

　　先決條件

　　該白皮文檔並不打算祥細的講述報表格服務。對於一些細節的資訊，可以到http://www.microsoft.com/sql/reporting/網站上查閱。除了報表格服務之外，該文檔假設讀者對以下內容已經熟悉：

　　◆Microsoft SQL Server

　　◆Internet Information Services (IIS)

　　◆Microsoft .NET 架構

　　這些資訊在MSDN網站上可以查閱http://msdn.microsoft.com。

　　概述

　　Reporting Services是一個綜合服務平台的Web的報表，用於建立、管理和交付傳統的紙張報表，同時具有互動性，。當執行報表時，Reporting Services平台執行如下步驟：

　　◆重新得到報表資料

　　◆根據報表指示和報表定義來處理資料

　　◆用特定的格式來顯示報表

　　Reporting Services也執行其他的任務來支援報表處理，如管理和處理訂閱，管理和處理快照和緩衝請求，和服務報告管理請求。

　　Reporting Services中的工作主要有三部分：

　　◆使用者可以線上互動訪問發行的報表

　　◆通過訂閱將預訂的和事務驅動的報表以Email或者檔案分享權限設定的形式交付給使用者

　　◆通過線上使用者即時地建立和自動的執行報表

　　本文的重點在第一部分，使用者可以線上互動訪問發行的報表。該功能對於大多數使用者來說是非常感興趣的。訂閱交付有可預訂的優點，使用者可以隨時隨地的進行控制。互動式報表更難進行計劃，因為大多數依賴於報表的大小和複雜度，並發使用者的多少和報表顯示的格式。使用者在應用互動式報表時，對系統響應速度也有較高的期待。

　　伴隨著SQL Server 2005 Reporting Services的出現，終端使用者可以通過新的報表產生器工具互動建立和執行報表。即時報表建立的額外負荷難於進行量化，因為這取決於使用者想做什麼和如何有效地做，即時報表的量化將在下一版本檔案中進行講述。本文主要包括一般的效能指導說明，建立互動式報表的負荷和在不同配置上進行測試。同時，最後的效能資料也取決於你自己的工作環境，你需要自行進行效能測試。本文中的圖片和結果主要為了說明在不同配置上可能出現的擴充特徵。

　　可擴充性vs可靠性

　　系統的可擴充性是很難定義的，因為對於不同的人有著不同的度量標準。容易引起混亂的是可擴充性和可靠性，它們常出現在同一文章中。可靠性對於任何的系統配置都是一個重要的考慮因素，它的存在或多或少的影響到了可擴充性。在本文中，可擴充性定義為：一種系統能力，能夠在不改變系統的基本設計和構架的基礎上支援系統工作量的增加。理想地，假如增加了系統資源，你應該增加相同比例的系統能力來處理更多的工作量。

　　這可能有點太直覺了，達到“準線形”的擴充性是非常困難的。在實際中，系統所需的能力並不能很好的滿足線形增長。這是因為管理、協作和通訊成本的超額也會在不同系統組件之間發生。系統可靠性是基於細微的不同看法。系統的可靠性是指“能夠順利地處理工作量增加，沒有出現任何失敗”。另外，當系統增加工作量時，可靠的系統應該能夠不間斷或者不同時停止工作。效能的退化也應該是一個平滑的過程。雖然，在壓力過大時，任何系統都可能變得無效，但是對於可靠的系統卻能夠從這些事故中進行恢複。對報表格服務進行成功的能力計劃重點是找到工作負載和系統能夠平滑處理的工作量，建立可靠的系統來滿足擴充需求。

　　向上擴充 vs 向外擴充

　　Reporting Services的可擴充性設計使使用者可以按照自己的意願在單個伺服器或者多個伺服器上部署組件。使用者開始用Reporting Services時經常問到“是買一個大伺服器(scale-up)還是買一個小的伺服器(scale-out)”。本文將描述這些可擴充性特性，來協助你解決這個問題。

　　一種向上擴充(scale-up)的方法是“利用大的、均勻的、多處理器的伺服器來提供額外的能力”。這種方法的優點是“相對於scale-out，它可以提供一種簡單的配置和管理過程”。scale-up同時也是SQL Serve關聯式引擎和分析服務的擴充方法。

　　向外擴充(Scale-out)，是企業版Reporting Services的一種配置，大多數使用者都喜歡用這種方法。重要的是，Scale-out能完成如下工作：

　　◆使使用者可以根據需要增加或者移除能力

　　◆提供一種可接受的、可管理的、可擴充的方式來增加和移除能力

　　◆允許繁重的工作量在許多日用伺服器上進行平衡

　　◆提供了一種內部錯誤的容許度

　　如果你想採用scale-out配置來部署Reporting Services，注意多報表伺服器之間的協作，使每個訪問單個報表伺服器的目錄安裝在一個本地或遠端SQL Server關聯式資料庫。對於細節的資訊請查看http://www.microsoft.com/sql/reporting/ 和http://technet.microsoft.com/sql.

　　報表格服務組件

　　為了更好的理解可擴充性，我們首先來瞭解一下報表格服務的體繫結構，如下圖1所示，還有各種組件。

　　圖1：報表格服務體繫結構

　　報表格服務可以分解為邏輯上的三層，如下表1所示：

　　表 1

組件	功能
報表伺服器	一個Web服務，做如下事情：·　　　　處理SOAP 和URL 請求·　　　　處理報表，包括執行查詢，檢查運算式，產生輸出格式·　　　　提供快照和報表緩衝管理·　　　　支援並加強安全性原則和權威性報表伺服器同時提供Windows服務，可以負責預訂和批處理操作，本文對此不作細述。
報表伺服器 目錄	以下兩種SQL Server資料庫構成目錄：·　　　　ReportServer包含報表內容資訊，有報表定義、報表中繼資料、資料來源定義、快照和曆史資料。它儲存了安全設定，賬戶資訊，預訂資訊和交付設定。·　　　　ReportServerTempDB裡麵包含的內容必須支援會話管理和報表的快取資料。這些目錄能夠駐留在同一物理系統如報表伺服器，或者單個的系統上（遠程目錄）。
客戶應用程式	客戶應用程式通過SOAP Web服務和URL請求來訪問伺服器。報表管理工具和報表檢視器應用程式是客戶應用程式，它們被包含在報表格服務中。Microsoft® Visual Studio® 2005提供了報表檢視器(Report Viewer)，用來控制嵌入在用戶端的報表。報表建立工具(Report Builder)是即時報表建立的權威工具。許多第三方軟體賣主也提供了他們自己的用戶端應用程式。

　　擴充規範

　　本節描述了報表格服務的基本配置選項，它們如何影響效能和擴充性。本節目的是協助使用者學習一種有效報表格服務配置和負荷需求，並回答如下問題：

　　◆你是否需要考慮把目錄部署到遠程伺服器上？

　　◆向上擴充報表伺服器和增加額外的報表伺服器那個更好？

　　◆對於你的4-處理器報表伺服器，什麼配置是最好的？

　　雖然微軟在不同的配置上所進行的測試導致了特定的報表工作量，實際的效能需求將依賴於你工作環境中的許多因素。包括如下因素：

　　◆並發使用者的數量

　　◆報表產生的大小和複雜度

　　◆按需報表和訂閱報表的產生

　　◆實況和緩衝報表的產生

　　以下章節的測試結果被用來決定各種不同配置的相對效能和可擴充性特徵。注意一些原始的規則如每秒查看的頁數，在不同的環境中將有所不同。主要關注像在環境中對資源進行分布處理或者添加資源所帶來的相對改進。後一章節提供了建立自己效能基準的指導。

　　本地vs遠程配置

　　微軟已經測試了兩個本地配置，運行報表伺服器和它的在單一的伺服器上的目錄。

　　圖2：本地目錄實施

　　在本地配置中，SQL Server關係型資料庫將和報表格服務競爭有效機器資源。如果你有充足的資源，那就沒有什麼問題了。

　　你可能考慮設定最大的記憶體和最多數量的處理器供SQL Server資料庫引擎使用，目的是為了減少和報表格服務的競爭，更多的資訊請看附錄A。客戶也選擇如圖2所示的配置，因為這僅僅需要SQL Server許可。

　　相反的，遠程目錄實現如圖3所示，通過兩個物理伺服器（報表格服務引擎和遠程目錄主機）來延伸報表格服務組件。

　　圖3：遠程目錄實現

　　遠程配置消除了機器資源之間的競爭。然而，你必須在報表伺服器和目錄伺服器之間提供充足的網路寬頻

　　向上擴充和向外擴充

　　在你拆分目錄到其他的系統之後，你可以選擇通過增加處理器來向上擴充報表伺服器，或者通過增加機器來向外擴充。圖4描述了一種採用多報表伺服器來訪問單個目錄的向外擴充配置。

　　圖4：採用多報表伺服器來訪問單個目錄的向外擴充配置

　　向外擴充的配置典型的是利用一個從任何報表伺服器節點分離出來的遠程關係型資料庫伺服器來管理目錄。它不可能將目錄存放在任何一個報表伺服器節點，這種配置是不值得推薦的，因為資料庫伺服器將消耗報表伺服器的資源。

　　一個4-處理器，向外擴充的配置使用2-處理器報表伺服器訪問一個遠程目錄。一個8-處理器，向外擴充的配置使用4個2-處理器報表伺服器。因此，向外擴充的配置增加的不僅僅是處理器，還有記憶體和網路互聯。

　　本地和遠程目錄效能比較

　　在可擴充性計劃中，第一個想法就是考慮報表伺服器目錄是採用本地的還是遠端模式。

　　在本地模式中，同一個物理機器管理了報表伺服器和報表伺服器目錄。目錄獨立於報表資料的來源資料庫，報表資料一般駐留在不同的伺服器上。

　　單機配置是最簡單的實現，也是最經濟的方式，但是有少許缺點。最重要的是，移動目錄到遠程伺服器是使用向外擴充配置的第一步。在隨後的章節中將進行討論。

　　為了回答採用增加處理器到本地的方式和拆分目錄方式那種方式更好，將採用如下的系統配置來進行測試：

　　◆2-處理器報表伺服器，本地目錄（2-proc local）

　　◆2處理器報表伺服器，遠程目錄(2-proc remote)

　　◆4-處理器報表伺服器，本地目錄(2-proc local)

　　◆4-處理器報表伺服器，遠程目錄(4-proc remote)

　　這些測試結果顯示了一些比較有意義的事實。

　　◆利用2-處理器系統，對於少許的負荷，本地和遠端執行結果大致相似。

　　◆4-處理器本地系統比2-處理器本地系統在每秒的請求中呈現較好效能；但也不是4-處理器遠程系統效能的兩倍。

　　表2顯示了四種配置在峰值能力時的比較結果，峰值能力是效能開始下降到高於30秒極限的會話最大數量。

　　表2

　　

	Avg Req / Sec	Peak sessions attained
2 Proc (Local)	Baseline	Baseline
2 Proc (Remote)	-10%	Baseline
4 Proc (Local)	53%	17%
4 Proc (Remote)	100%	117%

　　從2-處理器本地到2-處理器遠端實現，事實上對會話峰值沒有什麼影響。在輸送量方面有細微的下降，因為資料在網路之間的轉移。

　　在高工作量時，加倍本地目錄實現的處理器(2-processor local 到 4-processor local)並不能實質性的加倍可用資源。它僅僅在到達峰值會話時提供了細微的增加和在每秒的請求時的53%的改進。

　　然而，在遠程目錄配置上，使處理器數由2變為4可以帶來線性增加。採用4處理器時，請求數量峰值比會話峰值加倍的多。

　　關鍵點

　　◆假如你運行一個2-處理器本地系統，拆分目錄到其他的伺服器將導致整個系統效能的細微改變。

　　◆拆分目錄不能給管理和監控帶來什麼好處，因為系統不能在報表伺服器和資料庫處理之間分配資源。

　　◆假如你運行一個4-處理器的本地系統，拆分目錄到其他伺服器將出現明顯的效能改善。

　　◆對於擴充，遠程目錄實現的第一步是採用向外擴充配置

　　向上擴充

　　本節主要關注通過在遠程目錄配置中增加處理器(scaling up)來增加可用的能力和效能。在這情形下，向上擴充的配置從2-處理器擴充到4-處理器。在隨後的測試中，當回應時間超過了預定的極限時間30s時將達到極限，30s一般認為是使用者難於容忍的回應時間。

　　表3

　　

　　

	Average requests / second	Maximum # Sessions	Page Views Per Minute
2 Proc (remote)	10.71 (Baseline)	600 (Baseline)	604 (Baseline)
4 Proc (remote)	23.91 (123%)	1300 (117%)	1327 (120%)

　　每秒的平均請求數

　　在大量使用者使用時，一個4-處理器系統比2-處理器的遠程系統能夠處理明顯更多的請求。加倍在遠程目錄中的可用處理器數目比加倍每台伺服器平均請求有細微的增加。

　　會話的峰值

　　一個4-處理器遠程配置能夠支援比加倍一個2-處理器會話峰值更多的遠程實現。

　　每分鐘的頁面查看

　　每分鐘的頁面查看數折射了所能提供的頁面產生能力。當遠程目錄實現中的處理器由2個提高到4個時，你可以在高負荷時得到120%的頁面查看效能改進。

　　關鍵點

　　◆在你拆分報表目錄到獨立系統之後，使處理器由2個增加到4個時本質上是加倍了報表格服務的執行速度，而沒有降低響應速度。

　　◆測試是在伺服器上進行的，沒有2個或4個處理器。大量處理器系統的最佳化在以後的測試中將進行檢查。

　　向外擴充

　　本章節主要關注向外擴充配置的效能和能力情況。在微軟的測試中，報表伺服器事實上是在2-處理器遠程目錄實現中的複製品。因此，向外擴充的機器是2倍和4倍於所有的系統資源（記憶體、儲存空間和網卡）還有處理器。

　　當你將2-處理器遠程執行的系統能力與4-處理器和8-處理器向外擴充相比較時，通過向外擴充配置提供了接近線性擴充。以下表格總結了2-處理器，4-處理器和8-處理器改進的百分比。

　　表4

　　

	Peak page views/hr	Maximum simultaneous user session
2 Proc (remote)	10.71 (Baseline)	600 (Baseline)
2 X 2 Proc (remote)	23.87 (210%)	1300 (216%)
4 X 2 Proc (remote)	45.18 (378%)	2500 (416%)

　　比較每秒鐘的平均請求峰值和所支援的會話峰值，2 X 2-處理器向外擴充配置提供了比2-處理器遠程執行的線性值更好的結果。

　　從2 X 2-處理器向外擴充到 4 X 2-處理器向外擴充並沒有提供真實的線性擴充。而且，它不能提供明顯的能力改進，有89%的每秒請求改進和92%的所支援的會話峰值改進。

　　

　　關鍵點

　　◆向外擴充的方式提供了更好的低本高效，在不需要大量硬體投資的情況下獲得更好的能力

　　◆假如你期待繼續增加報表格服務需求，向外擴充是一種自行增加額外能力的彈性方式

　　比較向上擴充和向外擴充

　　一個直接的向上擴充和向外擴充的執行個體比較4-處理器遠程目錄和向外擴充的4-處理器。假設，4個處理器駐留在同一個報表伺服器裡，同時向外擴充利用2個2-處理器報表伺服器。

　　測試結果顯示在兩種實現之間僅有少許差別。向外擴充在兩個節點之間有8GB的記憶體，4-處理器遠程有4GB的記憶體。考慮同等的會話數量，4-處理器系統的回應時間比較均勻。4-處理器向外擴充在回應時間上有細微的優勢。期待將報表格服務部署在ASP中。網路應用程式正好迎合了向外擴充配置中便宜硬體組裝的優勢。

　　關鍵點

　　如果你有2-處理器遠程目錄實現，需要使能力翻倍，你向上擴充到4-處理器報表伺服器或者向外擴充到2個報表伺服器都沒有用。

　　儘管轉移到向外擴充配置需要你轉移到企業版的報表格服務，除原始能力外它有許多優點。主要包括如下：

　　◆少量處理器的伺服器比大型SMP伺服器要便宜得多

　　◆額外的機器可以利用保留記憶體位址空間，而不用轉移到64位的硬體上

　　◆用新伺服器添加能力，而不是升級已存在的伺服器，可以節省停工期

　　◆多樣的報表伺服器提供了更好的可用性，假如一個伺服器失敗了，其他的伺服器能夠繼續接受請求

　　◆你可以輕鬆的向外擴充到6、8或者10處理器。SMP伺服器一般在8處理器之後出現低效能回報

　　採用64位處理器

　　SQL Server 2005報表格服務支援64位處理器，包括Intel Itanium2處理器，AMD 和Intel的x64體繫結構處理器。在x64系統上，報表格服務能夠運行在原始的64位元模式和32位WOW(Windows on Windows)子系統上。總的來說，64位系統運行在同一處理器上並不能提高報表的生產量。但是，主要的優點是使用者可以查看和匯出更大的報表。當處於高工作量時，你可能在64位機器上會得到更好的生產量，因為記憶體競爭會下降同時記憶體回收會更少發生。微軟並不能夠全面地測試這些平台，但會利用測試結果有計劃的更新這些文檔。

　　報表緩衝和儲存

　　在報表格服務實現中，在效能和能力方面一個重要的因素是“實況地從原系統的資料中產生報表還是通過利用緩衝或者快照資料”。本節描述了一些選項，和潛在的效能影響選項。

　　緩衝執行個體

　　報表伺服器擁有兩層緩衝：

　　1．當報表伺服器產生報表時，它重新從報表伺服器目錄中得到報表定義，並從資料來源中得到報表所需的資料。然後建立臨時的報表格式（儲存在會話緩衝中），寫到ReportServerTempDB資料庫中。它利用這些結果，緩衝執行個體來建立並匯成最後的報表。

　　對於每一個完全的“實況”報表，它都要重複這些步驟。它可以指導後續報表的請求，如果該報表已經處理完了並存在緩衝中。這樣就可以減少重新檢索資料和建立報表的時間。

　　2．報表伺服器也會嘗試緩衝輸出格式，或者記憶體中的報表快照集，或者檔案系統中的臨時目錄。如果請求的結果在輸出緩衝中被找到，它將迂迴於處理和描寫步驟之間，因此將產生更好的效能。如果需要瞭解更多的關於如何決定使用何種緩衝，可以參閱附錄B中的效能統計類。

　　緩衝最終將會到期，導致重新從報表伺服器中擷取新的資料。你可以根據預先確定的時間間隔來控制緩衝期限，預定的（針對特定報表的或者共用的）或強制的期限。

　　緩衝報表對儲存有影響，雖然SQL Server 2005報表格服務能簡潔地儲存資料同時也能夠提供資料壓縮。當決定應該保持多少緩衝或者快照鏡像時，應該考慮如下事情：

　　◆當緩衝執行個體建立時，查詢參數被應用。如果你需要一個報錶帶有不同的查詢參數，報表格服務將產生額外的緩衝執行個體。

　　◆沒有用於查詢的報表參數，可以被用來從緩衝執行個體中建立不同報表版本。

　　報表快照集

　　快照涉及同樣時間間隔報表格式，儲存在一個更為持久的狀態。比如，快照可以儲存在報表伺服器目錄中，而不是儲存在ReportServerTempDB中。目錄也可以維持多時間間隔的版本，作為報表曆史，允許使用者在它們之間進行選擇。

　　SQL Server 2005報表格服務自動在目錄中壓縮快照。它也可以將快照鏡像儲存到本地檔案系統。以下的章節將突出利用緩衝執行個體所帶來的效能影響，壓縮快照，和檔案系統儲存。

　　緩衝執行個體

　　一種可以改進報表格服務部署的能力和規模的方式是避免執行依賴於實況資料的報表。你可以通過利用快取資料來進行。

　　圖5顯示了重新檢索、處理和描寫一個有150K行資料的報表，用實況和快取資料來執行。

　　圖5：150-K 行單個報表的時間計算

　　當聚集時，這些資料說明了相比採用緩衝，實況資料需要261%以上的時間來進行報表格服務。那些需要返回大量實況資料的報表，比採用快取資料方式的報表需要更加多的資源。

　　要求使用者在系統使用峰值時避免運行實況報表是不合理的。通常，使用者不能意識到運行這些報表會給系統效能和其他系統使用者帶來影響。一些“良民”實踐使你會考慮傳輸到你的使用者數來改進系統能力和響應，包括如下：

　　◆無論何時，避免使報表重新檢索，執行大量的實況資料。用快取資料來代替。

　　◆如果無法避免這種情形，至少嘗試著限制這樣的報表的運行數，尤其在高峰時間。

　　◆當可以從快取資料中產生報表時，在非高峰時間內預定這些報表來更新緩衝，以避免影響其他使用者。

　　壓縮快照儲存

　　SQL Server 2005報表格服務使管理員可以自行決定快照資料存放區在那裡，如何儲存。

　　使用快照能明顯的改進報表效能，但是消耗了資料庫儲存空間。為了協助平衡儲存和效能問題，報表格服務提供了壓縮選項。預設的設定是壓縮快照和報表定義。你也可以關閉壓縮。

　　比如，在一個20千行的報表中，SQL快照壓縮後減少了20%的壓縮前大小。減少的部分不僅翻譯到報表伺服器目錄中的重要儲存，而且大大的減少了報表伺服器和目錄之間的通訊量。