SSRS Reports 2008性能優化案例


我們的一個Reporting Service服務上部署了比較多的SSRS報表,其中有一個系統的SSRS報表部署后,執行時間相對較長,加之供應商又在ASP.NET頁面里面嵌套了Reporting Service的報表,使得用戶對報表響應速度非常不滿,於是和幾個同事研究了一番如何定位、優化SSRS報表性能。

   案例環境:

        操作系統   :   Windows Server 2008 R2 Standard SP1

        數據庫版本 :   SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64)

   現象描述:

    綜合了用戶、開發人員那邊反饋的問題后,發現該SSRS服務器上部署的其它系統的報表響應速度非常快,測試了其中幾張報表發現基本在1~3秒內,但是這個系統(模塊)的SSRS報表全部比較慢,基本上都8秒以上。而且是第一次訪問非常慢,如果刷新或第二次訪問非常快,但是如果修改報表URL參數時,也會非常慢。於是我就其中一個報表為例,查看該報表的的執行日志信息,如下所示,我們通過ExecutionLog與Catalog關聯查看報表WF_MarkerRoom_Report的執行記錄。具體細節可以參考一下Reporting Services 執行和跟蹤日志記錄

 
USE [ReportServer];
GO
 
SELECT  C.Name                         AS ReportName
       ,E.ReportID                     AS ReportID
       ,E.UserName                     AS UserName
       ,E.Format                       AS Format
       ,E.Parameters                   AS Parameters
       ,E.TimeStart                    AS TimeStart
       ,E.TimeEnd                      AS TimeEnd
       ,E.TimeDataRetrieval*1.0/1000   AS TimeDataRetrieval
       ,E.TimeProcessing*1.0/1000      AS TimeProcessing
       ,E.TimeRendering*1.0/1000       AS TimeRendering
       ,DATEDIFF(SECOND, TimeStart, TimeEnd)
                                       AS  CostTime
FROM ReportServer.dbo.ExecutionLog E WITH(NOLOCK)
INNER JOIN ReportServer.dbo.Catalog C WITH(NOLOCK)ON E.ReportID = C.ItemID
WHERE C.Name ='WF_MarkerRoom_Report'
   AND E.TimeStart > CAST('2014-12-25 00:00' AS DATETIME)
  AND E.TimeStart <= CAST('2014-12-25 12:00' AS DATETIME)
ORDER BY TimeStart DESC

                                                                                                      部分執行結果截圖

clipboard

 

   從上可以看出報表的時間消耗在TimeDataRetrieval上,TimeDataRetrieval是SSRS檢索數據、處理報表以及呈現報表所用的毫秒數(SQL里面,我轉化為秒),於是我們首先懷疑是報表里面的SQL語句性能問題,於是將報表里面涉及的SQL語句、存儲過程全部取出驗證測試,結果測試發現所有SQL語句執行時間幾百毫秒,沒有超過1秒, 這個設想與驗證結果有很大出入,於是又懷疑是否因為SSRS報表都是傳入存儲過程參數獲取數據,是否因為“參數嗅探”導致測試結果有差異,於是修改、驗證發現依然測試結果不到一秒。於是可以斷定問題還是出在SSRS上, 以前碰到過因為安全驗證導致過報表超時的案例,但是除了這個模塊SSRS報表依然很慢。其它模塊報表速度非常快,如果是安全驗證問題,應該其它報表速度也會有問題。很是納悶,也檢查了很多設置,依然沒有答案。

    問題究竟出在哪里呢?經過一番虐心的仔細對比后,居然發現其它模塊的報表,在數據源設置上使用SQL認證的方式連接數據庫,而這個模塊使用的Windows認證方式訪問數據庫,於是我嘗試將報表的數據源連接方式改為一個SQL認證的賬號,從 Windows Authentication using a domain account改為SQL Authentication

clipboard[1]

clipboard[2]

如上所示,測試SSRS報表的速度結果以及TimeDataRetrieval時間讓人吃驚,在官網論壇也有看到討論:Performance Issue with Shared DataSources using Windows vs SQL Authentication  應該是使用Windows認證方式(Windows Authentication Using a Domain Account)需要涉及加密、域賬號認證等消耗了不少時間。 當然,由於對SSRS了解不是非常深入,也沒法分析得更深入,在官方文檔“性能比較: 安全性設計選擇(構建分布式應用程序)”里面,我們可以看到不同的認證方式的Response Time不一樣。我想SSRS應該也不例外。

image

 

 

參考資料:

http://msdn.microsoft.com/zh-cn/library/bb934330.aspx

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/43d09604-cc7a-479e-810f-a141f5f402f0/performance-issue-with-shared-datasources-using-windows-vs-sql-authentication?forum=sqlreportingservices


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM