前几天一同事反映海外工厂A的SSRS报表比较慢，让我检查优化一下。于是我检查了下2015-07-13到2015-07-15 12:00这段时间报表的耗时记录
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 E.TimeStart > CAST('2015-07-13 00:00' AS DATETIME)
AND E.TimeStart <= CAST('2015-07-15 12:00' AS DATETIME)
ORDER BY TimeStart DESC
如上所示，我当时初步一看（没有细看），SSRS的速度还可以啊， 因为SSRS一般2~3秒的速度相当不错了，当时也很忙，我就直接回复该同事说SSRS性能没有问题，后面他邮件回复我说，SSRS的报表有时候很不正常，有时耗费比较长的时间，如上所示，有时候需要耗费10~12秒，严重影响了他那边的应用程序（应用程序调用SSRS）；他还用我上面的脚本对比了海外工厂B的SSRS报表速度，发现那个工厂的SSRS报表的速度几乎为2秒，这才引起我的注意。从查询的记录来看，SSRS报表的SQL语句取数并没有耗费多少时间，报表基本上都耗费在TimeProcessing和TimeRending上，也就是说时间耗费在处理报表以及呈现报表上。但是为什么会这样不稳定呢？ 刚开始我也有点纳闷！后来我想检查一下服务器的配置信息，但是又没有权限，同事找当地的系统管理员，系统管理员帮忙在他电脑用VNC登录服务器，然后他通过Lync共享桌面给我，检查的时候，突然发现一个雷死人的事情，该服务器CPU只分配了两核，对，你没有看错。如下截图所示，有时候CPU利用率就会突然彪增到100%， 持续一分钟左右又会降下来。而SSRS如果在那个时候调用的话，处理报表和呈现报表的时间就会突然增加。导致SSRS呈现报表需要非常长的时间。很明显该服务器在CPU资源上存在瓶颈，于是邮件通知当地系统管理员以及这边的几位老大关于这个问题。让海外工程的系统管理员增加CPU资源。
服务器增加了CPU资源，由原来的2核增加到4核后，我第二天去检查时，发现SSRS报表的速度明显有所改善，如下所示。这样的案例真是有点匪夷所思，我只能呵呵了。哎！
