使用 Reporting Service 呈现 MDX 查询的结果非常慢(大约 8-10 秒)。MDX 速度很快,确实有一些条件渲染,但 8 秒对于 60x10 的表格来说听起来像是一个可怕的时间。
我们使用了 Can Grow/Shrink,但缓慢的性能仍然存在。
有人有同样的经历吗,性能是一个普遍的 SSRS 问题,还是我们添加了一些导致这个瓶颈的“功能”?
使用 Reporting Service 呈现 MDX 查询的结果非常慢(大约 8-10 秒)。MDX 速度很快,确实有一些条件渲染,但 8 秒对于 60x10 的表格来说听起来像是一个可怕的时间。
我们使用了 Can Grow/Shrink,但缓慢的性能仍然存在。
有人有同样的经历吗,性能是一个普遍的 SSRS 问题,还是我们添加了一些导致这个瓶颈的“功能”?
更多的一般性答案。我有一些降低性能的例子。
强烈建议使用查询对基本上任何数据操作进行排序、分组、求和等。
不太确定你的报告中有什么。
希望其中一些帮助?
正如另一个答案中指出的那样,问题是canGrow。但这有点棘手。我们如何设法解决问题:
1) 使用浏览器调试器(IE 中的 F12)并分析 java 脚本代码。如果问题是一个增长问题,您会看到一个名称中带有增长的方法几乎一直在占用。
2)比直接在rdl文档中编辑所有单元格的属性替换更好。在我们的例子中,使用标准文本编辑器(例如 Notepad++)删除所有“真实”条目。
3)再次检查,在我们的示例中可能仍然存在一些cangrow,这是由于图标不太容易删除但改进很大。