Reporting Services ExecutionLog:timestart和timeend之间发生的事情

时间:2012-04-20 15:37:42

标签: sql-server-2008 reporting-services ssrs-2008

我一直在调查一份报告服务报告,该报告从一夜之间变得非常敏捷到非常缓慢。查看执行日志,并检查开始和结束时间之间的差异,我得到的内容如下:

  • 第1天= 900毫秒
  • 第2天= 900毫秒
  • 第3天= 2000毫秒
  • 第4天= 4500毫秒
  • 第5天= 4500毫秒

该报告在一年多的时间内表现得非常活跃,其性能与第一天相似,直到几周前,现在我们一直处于这个更高的数字。通过我们通常用于获取呈现的PDF以及通过Web UI的webservice调用,我们具有相同的性能。

在指出的性能变化期间,报告本身未被更改或重新部署。也没有对涉及的服务器进行任何硬件更改。

查看日志详细信息,我对这个额外时间的来源感到困惑。

  • TimeDataRetrieval是一个稳定的20毫秒
  • TimeProcesing大约50毫秒
  • TimeRendering稳定在600毫秒

所以这一切应该弥补约700毫秒。什么是TimeStart和TimeEnd会计以及这3个值?这似乎是我们的性能问题所在,但我不知道还有什么。

我们正在Windows Server 2003 SP 2上使用报表服务2008,如果可能的话 差。

提前致谢, 韦斯



编辑[2012-04-30]:

我们还调查了其他报告,并发现它们同时遭受同样的性能损失,因此它似乎与报告本身无关。

我还让我们的网络管理员在其上创建了一个带有报告服务的新VM,向其部署了相同的报告,发现我们的时间回到了900毫秒以下,报告定义和数据源完全相同。我真的不想将所有指向我们旧的报表服务器的项目迁移到一个新的项目,但看起来这可能至少暂时解决了问题,直到它再次变得难看。

任何关于尝试途径的后续想法,即使它们只是猜测也会受到赞赏。

再次感谢,Wes



编辑[2012-05-12]:

我还确保我们的报表服务器和报表服务器临时数据库重建了索引并更新了统计信息,并考虑如果我们从执行索引查找到表扫描或类似的东西,它可能导致全面放缓。这两种选择都没有帮助。

我们现在已经在新VM上重新部署了所有报告,并且运气好得多,尽管在此过程中也升级到2008 R2,这可能会提升性能。从问题的用户方面来看,问题已经解决了,但是我仍然不知道我对减速的来源不知道。

0 个答案:

没有答案