我只是想知道报告服务在返回1MB数据时需要多长时间(几分钟)来生成报告。也许使用视图和表是正确的索引。 SSRS报告和服务器端生成。

解决方案

可以接受多长时间？取决于它在做什么，它运行了多少，类似的事情。如果每天运行一两天，则30秒以下的时间都可以。如果每周运行一次，或者每月运行一次，那么这个数字可能会更高。

报表本身通常非常快，如果我们遇到挂断，则可能需要检查生成数据的查询的执行时间。即使只返回少量数据，复杂的查询也可能花费很长时间。

我发现，在使用BIRT和其他报告系统时，最好的改进往往是通过将大部分工作卸载到后端数据库来实现的。

换句话说，不要在网络上发送大量数据并在本地对数据进行分类或者分组。几乎可以肯定，该数据库的SQL orderby和groupby子句以及优化索引(以及其他功能)的性能将超过我们。

这样，我们可以更快地提取所需的数据，并减少网络流量。

报表生成时间包含两个部分：
数据采集​​时间
渲染时间

那么对于1 Mb的数据，我们正在谈论多少记录(行)？报告将包含几页？每页多少个控件？报告是否使用图表？这些是决定生成时间的因素。

对于大多数报告，数据采集时间是最重要的因素。报告运行速度永远不会比原始数据采集快。因此，如果我们使用的是SQL，则报表的生成速度不会比运行查询所需的时间快。我已经看到查询返回的数据很快就超过了1Mb。我还看到查询返回的数据很少，并且运行了很长时间。

在渲染方面，有几件事可能导致报表运行缓慢。首先是报告汇总。如果报表需要在开始呈现之前接收所有记录，则其性能将受到影响。特别是，取决于报告工具。对于大型数据集(超过10,000条记录)，可以通过在源(DB)上进行聚合来显着改善渲染。另一个是制图，这通常涉及大量渲染开销和聚合。

大多数报告系统都允许我们内置计时器或者日志记录，以对报告进行性能调整。最好在报告中内置计时器，以告诉我们报告花费在数据获取上的时间百分比以及花费在呈现上的百分比。当我们获得这些信息时，我们将知道将精力集中在哪里。

如果我们确实要评估报告工具的性能，则最好的方法是构建一个报告，该报告可以读取平面文件或者通过代码生成数据。换句话说，消除数据库的影响，并查看报告工具生成页面的速度。

希望这可以帮助。