我只是想知道报告服务在返回 1MB 数据时生成报告需要多长时间(以分钟为单位)。也许使用视图和表是正确的索引。SSRS 报告和服务器端生成。
5 回答
报告生成时间有两个组成部分: - 数据采集时间 - 渲染时间
那么对于 1 Mb 的数据,我们在谈论多少条记录(行)?报告将有多少页?每页有多少个控件?报告是否使用图表?这些是决定生成时间的因素。
对于大多数报告,数据采集时间是最重要的因素。您的报告永远不会比原始数据采集运行得更快。因此,如果您使用 SQL,则生成报告的速度不会快于运行查询所需的时间。我看到查询很快返回超过 1Mb 的数据。我还看到了返回非常少数据的查询,这些查询运行了很长时间。
在渲染方面,有几件事会导致报表运行缓慢。第一个是报告聚合。如果一个报表需要在开始渲染之前接收所有的记录,那么它的性能就会受到影响。特别是,取决于报告工具。对于大型数据集(超过 10,000 条记录),您可以通过在源 (DB) 处进行聚合来显着改进渲染。另一个是图表,它通常涉及大量的渲染开销和聚合。
大多数报告系统允许您内置计时器或日志记录,以帮助您调整报告的性能。最好在报告中构建计时器,它会告诉您报告用于获取数据的时间百分比,以及用于渲染的时间百分比。当你掌握了这些信息,你就会知道应该把精力集中在哪里。
如果您真的想评估报告工具的性能,最好的方法是构建一个可以读取平面文件或通过代码生成数据的报告。换句话说,消除数据库的影响,看看你的报告工具能多快生成页面。
希望这可以帮助。
多长时间可以接受?取决于它在做什么,它运行了多少,诸如此类。如果每天或每天运行一次,任何低于 30 秒的时间都可以。如果它每周或每月运行一次,这个数字可能会高得多。
报告本身通常非常快,如果您看到挂起,您可能需要检查生成数据的查询的执行时间。一个复杂的查询可能需要很长时间,即使它只返回少量数据......
我发现,在使用 BIRT 和其他报告系统时,最好的改进往往是通过将大部分工作卸载到后端的数据库来实现。
换句话说,不要通过网络发送大量数据并在本地对其进行排序或分组。几乎可以肯定,该数据库的 SQL orderby 和 groupby 子句以及优化索引(除其他外)将超越您。
这样,您可以更快地提取所需数据并减少网络流量。
正如一些人已经说过的那样,这样的一般问题确实无法回答。但是,我写了Turbo-charge Your Report Speed – General Rules & Guidelines(免责声明 - 我是 Windward Reports 的 CTO,SSRS 的竞争对手)。我认为这将帮助您寻找可以做些什么来加快这个过程。
关于细节的所有警告都非常重要,在 3GHz 工作站上,我们通常会看到 7-30 页/秒。请记住,这是 Windward 的数字,而不是 SSRS。