SSRS Reports 2008性能优化案例

  • 时间:
  • 浏览:0
  • 来源:uu快3计划_uu快3官方_单双

   从上可不能否 看出报表的时间消耗在TimeDataRetrieval上,TimeDataRetrieval是SSRS检索数据、除理报表以及呈现报表所用 的毫秒数(SQL里边,我转化为秒),于是我们都我们都儿儿首先怀疑是报表里边的SQL一句话性能间题,于是将报表里边涉及的SQL一句话、存储过程完正取出验证测试,结 果测试发现所有SQL一句话执行时间几百毫秒,非要超过1秒, 你这名设想与验证结果有很大出入,于是又怀疑有无不可能 SSRS报表都在传入存储过程参数获取数据,有无不可能 “参数嗅探”原困 测试结果有差异,于是修改、验证 发现依然测试结果非要一秒。于是可不能否 断定间题还是出在SSRS上, 完后 碰到过不可能 安全验证原困 过报表超时的案例,以后除了你这名模块SSRS报表依然很慢。其它模块报表带宽非常快,不可能 是安全验证间题,应该其它报表带宽也会有间题。很是纳闷,也检查了所以设置,依然非要答案。

        操作系统   :   Windows Server 60 8 R2 Standard SP1

   间题描述:

                                                                                                      要素执行结果截图

如上所示,测试SSRS报表的带宽结果以及TimeDataRetrieval时间以后你吃惊,在官网论坛都在都看讨论:Performance Issue with Shared DataSources using Windows vs SQL Authentication  应该是使用Windows认证依据(Windows Authentication Using a Domain Account)须要涉及加密、域账号认证等消耗了不少时间。 当然,不可能 对SSRS了解都在非常深入,也非要分析得更深入,在官方文档“性能比较: 安全性设计选泽(构建分布式应用守护程序运行运行)”里边,我们都我们都儿儿可不能否 都看不同的认证依据的Response Time不一样。以后以后我应该 SSRS应该所以例外。

    综合了用户、开发人员那边反馈的间题后,发现该SSRS服务器上部署的其它系统的报表响应带宽非常快,测试了其中几张报表发现基本在1~3秒内,以后你这名 系统(模块)的SSRS报表完正先要,基本上都8秒以上。以后是第一次访问非常慢,不可能 刷新或第二次访问非常快,以后不可能 修改报表URL参数时,也会非 常慢。于是以后你其带有4个 报表为例,查看该报表的的执行日志信息,如下所示,我们都我们都儿儿通过ExecutionLog与Catalog关联查看报表 WF_MarkerRoom_Report的执行记录。具体细节可不能否 参考一下Reporting Services 执行和跟踪日志记录

        数据库版本 :   SQL Server 60 8 R2 (SP2) - 10.60 .60 0.0 (X64)

 我们都我们都儿儿的有4个 Reporting Service服务上部署了比较多的SSRS报表,其带有有4个 系统的SSRS报表部署后,执行时间相对较长,加之供应商又在ASP.NET页面里边嵌套了 Reporting Service的报表,使得用户对报表响应带宽非常不满,于是和十哪几个 同事研究了一番怎样才能定位、优化SSRS报表性能。

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

   案例环境: