大家都希望找到高性能的报表工具，但如何准确考察报表工具的性能并非易事，简单看厂商出具的报告并不一定准确，更靠谱的做法还是亲手测试。本文就来讨论应该如何评测报表工具的性能。
报表运行的整个周期如下图：

从请求后，报表经历数据准备、数据传输、报表计算、报表生成及页面渲染几个环节。

性能问题会集中在两个阶段：其一为报表数据源的准备和传输；其二为报表的计算与呈现（页面渲染）。实际上，大部分报表性能问题都出现在第一个阶段，即数据准备缓慢或传输缓慢，虽然这是影响报表性能的关键，但很多报表工具并没有在这方面提供有力的支持，所以无法对比这两个环节。这样，也就只好先看看能比的报表计算与呈现阶段了，这也是报表工具的自身能力所在。

下面我们来设计用于测试报表工具计算和页面渲染环节性能时的用例及相应方法，分为两个环节：
（1）报表的计算能力；
（2）页面渲染能力，渲染涉及的内容较多，比如分页或不分页、样式以及数据量等。

计算性能

主要考察格间计算，报表中单个格子以及格子之间的计算要多一些且复杂，计算越复杂越能充分考验工具的性能，较容易爆出问题。另外，数据量小的情况下也难以看出差异，可以不断加大数据量从而加大计算格子数，达到一定规模也就能对比出性能方面的问题了。
基于此，我们设计一个报表来测试对比报表工具的格间计算性能。

用例：“产品销售情况汇总”

用到 4 个表“订单、订单明细、类别、产品”，数据结构分别为：

订单表：

订单明细表：

类别表：

产品表：

设计的报表模板中涵盖多个复杂的格间计算，如销售额及销售数量在品类、产品中的排名及占比等。

基于上面的数据库表及报表结果，定义报表取数 SQL 为：
SELECT 类别.类别名称,产品.产品名称,类别.类别ID,订单.雇员ID,订单明细.订单ID,订单明细.数量,订单明细.单价*订单明细.数量 金额 FROM 订单明细,类别,产品,订单 WHERE 订单明细.产品ID = 产品.产品ID AND 产品.类别ID = 类别.类别ID AND 订单明细.订单ID =订单.订单ID

再通过控制查询人数（SQL 后加一个条件：AND 雇员 ID<?）来增加数据量，不断增加计算的格子数统计耗时情况。
然后可通过控制台或日志文件查看具体用时，比如测试润乾报表时会看到如下日志：

从“取数结束，开始运算”到“计算结束”即为工具计算报表用时，其他工具也有类似的日志输出。
在同台服务器、相同的软硬件环境下，多次测试就可以得到对比结果。

如下是针对润乾报表和另一款常用的报表工具的测试对比结果，JVM 内存设置为 2G：

从上面的测试过程可以看出，小数据量比不出差别。当不断加大数据量，随着格间计算格子数的增多，性能优劣就逐渐显现出来了，达到一定规模后，甚至可能发现性能急剧下降的现象。

页面渲染性能

报表在计算完成后，生成 html 脚本的同时会添加各种格式外观属性，包括像字体颜色、格子背景色、条件前 / 背景色等。
考察报表工具渲染性能力时，用例在报表格式上不需要复杂，而要有意识地增加一些条件色（如根据某些数据的区间设置不同的字体颜色），让报表渲染变的更复杂，同样也会不断增加数据量增加渲染的格子数，更全面的测试该部分的性能。
同样，这里我们也可以设计一个报表来测试报表工具的页面渲染能力。

用例：”订单详情表”

数据表仍然使用上面用例的 4 个“订单、订单明细、类别、产品”。

报表设计为常见的行式报表，结果共含有 34 列（截图为部分列）

基于数据表及报表结果，定义数据集 SQL 为：
SELECT * FROM 订单明细,类别,产品,订单 WHERE 订单明细.产品ID = 产品.产品ID AND 产品.类别ID = 类别.类别ID AND 订单明细.订单ID =订单.订单ID

接下来，为报表模板增加复杂的条件样式：
订单数量：多于 20 前景色为红色、小于等于 5 绿色、其他为黑色
库存量：小于 30 前景色红色预警、大于 500 蓝色且加粗字体
销售额：小于等于 100 前景色绿色、大于 100 且小于等于 300 蓝色、大于 300 且小于等于 500 紫色、大于 500 且小于等于 1000 橙色、大于 1000 为红色且加粗字体
到货日期：如果发货和到货日期超过 10 天，则标注为红色
也可以再多增加其他设置，比如运货费的判断等等，尽量多一些。
最后，通过查询订单个数（SQL 后加一个条件：AND 订单 ID<?）来控制数据量，用时同样参考报表工具的控制台或日志输出就可以了。

下面是本用例在同浏览器，JVM 仍是 2G 的环境，针对润乾报表和另一款常用报表工具，经过多次测试后平均用时对比情况：

同样可以看出，小数据量下看不出差别，要不断加大数据量，到一定规模就能很明显的看出性能差异了，严重情况还会发生内存溢出的现象。
通过以上用例，掌握了测试性能的思路和方法，就方便我们亲自上手对比了。

总结

报表的性能好坏不像是可视化，上眼一瞧还能有个基本判断。光听厂家说性能怎么好，被忽悠的概率极高。所以，最好还是搞用例亲自测试下，就像上面的实例结果一样，这样更具有说服力。

最后，还是要说下关于数据源准备的问题。前面已经提到，它是报表性能的关键因素。然而，报表工具却并不认为这是自身的问题，以至于几乎都未提供这部分的解决方案，所以无法进行比较，也不能通过更换报表工具来解决这部分运行缓慢的问题。

不过，也不都是所有工具都懒于解决，润乾报表就集成了自家开源的 SPL 产品，凭借其脚本能力，能够为数据源准备阶段提高效率。例如，它可以替代复杂的 SQL 或存储过程；还能通过并行取数来解决传输慢的问题等。这样一来，就解决了整个报表运行周期内各个环节运行缓慢的问题，这才算是真正好用的工具应具备的特性。