如何对 BIRT 报告性能进行基准测试？

Question

我有一份关于性能问题的 BIRT 报告：运行大约需要 5 分钟。

一开始我认为问题出在数据库上：这个报告使用了一个相当复杂的 SQL Server 存储过程来检索数据。经过大量 SQL 优化后，此过程现在需要大约 20 秒才能运行（在管理控制台中）。

但是，报告本身仍然需要太多时间（几分钟）。如何识别 BIRT 报告生成中的其他瓶颈？有没有办法分析整个过程？我正在使用 www 查看器（在 Tomcat 5.5 中运行）运行它，并且我没有任何 Java 事件处理程序，一切都是使用标准 SQL 和 JavaScript 完成的。

我观看了网络研讨会“设计高性能 BIRT 报告” 1，它有一些有趣的考虑，但并没有太大帮助......

Answer 1

当我写这个答案时，这个问题已经快两年了，所以想必你已经找到了解决这个问题的方法。没有人为整个过程提供分析器，因此这里有一些识别瓶颈的方法。

1. 启动时间 - 这里大约需要一分钟

   • 依次运行几个报告或在第一个报告运行后启动第二个报告可以帮助诊断问题。

2. SQL 查询运行时 - 问题中提到了好的解决方案

   • 任何 SQL 跟踪和性能测试都会发现问题。

3. 构建报告 - 我注意到这是花费大部分时间的地方。创建报告时运行 SQL 跟踪。在 SQL 跟踪指示查询完成后，即使是包含大量数据的相对简单的表也可能需要大约一分钟的时间来配置和显示（通过 apache tomcat 的 HTML） 。

   • 简化报告或使用更少的图形或表格创建一个克隆，在有或没有片段的情况下运行，以查看是否有任何显着差异
   • 修改查询带回更少的记录，更少的记录更容易显示，

4. 交付方式 PDF、Excel、HTML 每种方式都可能存在不同的问题

   • 尝试不同格式的报告
   • 如果其中一个明显更大，请尝试不同的发射器。