生成报告所需的最长时间
我只是想知道报告服务返回 1MB 数据时需要多长时间（以分钟为单位）生成报告。 也许使用视图和表是正确的索引。 SSRS 报告和服务器端生成。
I am just curious to know how long, in minutes, does the reporting service take to generate report when it returns 1MB of data. Maybe using views and table is properly index. SSRS reporting and server side generation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
报告生成时间由两个部分组成：
- 数据采集时间
- 渲染时间
那么对于 1 Mb 的数据，我们讨论的是多少条记录（行）？ 报告有多少页？ 每页有多少个控件？ 报告是否使用图表？ 这些是决定生成时间的因素。
对于大多数报告来说，数据采集时间是最重要的因素。 您的报告永远不会比原始数据采集运行得更快。 因此，如果您使用 SQL，则生成报告的速度不会快于运行查询所需的时间。 我见过查询非常快地返回超过 1Mb 的数据。 我还看到过返回很少数据且运行时间很长的查询。
在渲染方面，有一些因素可能会导致报表运行缓慢。 第一个是报告聚合。 如果报表需要在开始呈现之前接收所有记录，那么其性能将会受到影响。 特别是，取决于报告工具。 对于大型数据集（超过 10,000 条记录），您可以通过在源 (DB) 进行聚合来显着改进渲染效果。 另一个是图表，它通常涉及大量的渲染开销和聚合。
大多数报告系统允许您内置计时器或日志记录，以帮助您调整报告的性能。 最好在报告中构建计时器，它会告诉您报告花费在获取数据上的时间百分比以及渲染花费的时间百分比。 当你掌握了这些信息后，你就会知道应该把精力集中在哪里。
如果您确实想评估报告工具的性能，最好的方法是构建一个读取平面文件或通过代码生成数据的报告。 换句话说，消除数据库的影响，看看您的报告工具生成页面的速度有多快。
希望这可以帮助。
Report generation time has two components:
- Data Acquisition time
- Render Time
So for 1 Mb of data, how many records (rows) are we talking? How many pages will the report have? How many controls per page? Does the report use charting? These are the factors that will determine generation time.
For most reports, data acquisition time is the most significant factor. Your report is never going to run faster than the raw data acquisition. So if you are using SQL, the report can't generate faster than the time required to run the query. I have seen queries that return far more than 1Mb of data very quickly. I have also seen queries that return very little data, that run for a long time.
On the render side, there are a couple of things that that can cause a report to run be slow. The first is in report aggregation. If a report needs to receive all of the records prior to starting rendering, then its performance will suffer. In particular, depending on the reporting tool. With large data sets (more than 10,000 records), you can have significant improvements in rendering by doing aggregation at the source (DB). The other is charting, which typically involves heavy rendering overhead and aggregation.
Most reporting systems allow you to build in timers or logging that will help you to performance tune the report. It is best to build timers into the report that will tell you what percentage of time the report is spending getting the data, and what percentage is spent rendering. When you have this information, you will know where to focus your energies.
If you are really trying to evaluate the performance of the reporting tool, the best way is to build a report that either reads a flat file or generates the data through code. In other words, eliminate the impact of the database and see how fast your reporting tool can generate pages.
Hope this helps.
多长时间可以接受？ 取决于它在做什么、运行了多少等等。 如果每天或每两天运行一次，任何低于 30 秒的时间都可以。 如果每周运行一次或每月一次，这个数字可能会高得多。
How long is acceptable? Depends on what it's doing, how much it's run, things like that. Anything below 30 seconds would be fine if it's run once every day or two. If it's run once a week or once a month that number could be a lot higher.
报告本身通常非常快，如果您看到挂起，您可能需要检查生成数据的查询的执行时间。 复杂的查询可能需要很长时间，即使它只返回一点数据......
The report itself is generally very fast, if you're seeing a hangup you may want to check the execution time of the query which generates the data. A complex query can take a long time, even if it only returns a little data...
我发现，在使用 BIRT 和其他报告系统时，最好的改进往往是将大部分工作转移到后端的数据库中。
换句话说，不要通过线路发送大量数据并在本地对其进行排序或分组。 数据库的 SQL orderby 和 groupby 子句以及优化索引（除其他外）几乎肯定会超越您。
这样，您就可以更快地提取所需的数据并减少网络流量。
I've found, when using BIRT and other reporting systems that the best improvements tend to come by offloading most of the work to the database at the back end.
In other words, don't send lots of data across the wire and sort or group it locally. The database is almost certainly going to outperform you with its SQL orderby and groupby clauses and optimizing indexes (among other things).
That way, you get faster extraction of the data you want AND less network traffic.
正如一些人已经说过的，像这样的一般性问题确实无法回答。 但是，我写了 提高您的报告速度 – 一般规则和规则 指南（免责声明 - 我是 Windward Reports 的 CTO，该公司是 SSRS 的竞争对手）。 我认为这将帮助您寻找可以采取哪些措施来加快这一过程。
尽管有关细节的所有注意事项非常重要，但在 3GHz 工作站上，我们通常看到每秒 7-30 页。 请记住，这是 Windward 的数字，而不是 SSRS 的数字。
As several said already, a general question like this really can't be answered. However, I wrote up Turbo-charge Your Report Speed – General Rules & Guidelines (disclaimer - I'm the CTO at Windward Reports, a competitor of SSRS). I think that will help you look for what you can do to speed up the process.
And with all the caveats about the specifics matter a lot, on a 3GHz workstation we generally see 7-30 pages/second. Keep in mind this is numbers for Windward, not SSRS.