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

                                                                                                      部分执行结果截图

 

   从上可以看出报表的时间消耗在TimeDataRetrieval上，TimeDataRetrieval是SSRS检索数据、处理报表以及呈现报表所用的毫秒数（SQL里面，我转化为秒），于是我们首先怀疑是报表里面的SQL语句性能问题，于是将报表里面涉及的SQL语句、存储过程全部取出验证测试，结果测试发现所有SQL语句执行时间几百毫秒，没有超过1秒， 这个设想与验证结果有很大出入，于是又怀疑是否因为SSRS报表都是传入存储过程参数获取数据，是否因为“参数嗅探”导致测试结果有差异，于是修改、验证发现依然测试结果不到一秒。于是可以断定问题还是出在SSRS上， 以前碰到过因为安全验证导致过报表超时的案例，但是除了这个模块SSRS报表依然很慢。其它模块报表速度非常快，如果是安全验证问题，应该其它报表速度也会有问题。很是纳闷，也检查了很多设置，依然没有答案。

    问题究竟出在哪里呢？经过一番虐心的仔细对比后，居然发现其它模块的报表，在数据源设置上使用SQL认证的方式连接数据库，而这个模块使用的Windows认证方式访问数据库，于是我尝试将报表的数据源连接方式改为一个SQL认证的账号，从 Windows Authentication using a domain account改为SQL Authentication

如上所示，测试SSRS报表的速度结果以及TimeDataRetrieval时间让人吃惊，在官网论坛也有看到讨论：Performance Issue with Shared DataSources using Windows vs SQL Authentication  应该是使用Windows认证方式（Windows Authentication Using a Domain Account）需要涉及加密、域账号认证等消耗了不少时间。 当然，由于对SSRS了解不是非常深入，也没法分析得更深入，在官方文档“性能比较： 安全性设计选择（构建分布式应用程序）”里面，我们可以看到不同的认证方式的Response Time不一样。我想SSRS应该也不例外。

 

 

参考资料：

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