SSRS Reports 2008性能优化案例

  1. 云栖社区>
  2. 博客>
  3. 正文

SSRS Reports 2008性能优化案例

潇湘隐者 2016-04-26 11:59:13 浏览2039
展开阅读全文

 我们的一个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

网友评论

登录后评论
0/500
评论
潇湘隐者
+ 关注