影响报表性能的几个因素
影响报表性能的几个因素
在软件项目中，用户常常会抱怨报表查询特别慢，甚至慢的不能忍受。这给开发人员带来巨大的压力。那么，报表的处理过程如何划分？处理过程中有哪些环节容易出现性能问题？如何优化这些环节呢？
我们先看一下报表处理过程中的各个环节划分，如下图：
图1：报表处理过程示意图
如图所示，报表处理过程为：
1、用户选择报表输入参数后，报表引擎会根据报表模板和输入参数来解释报表，并将
数据计算和读取请求发送给数据层。
2、数据层负责读取、计算和返回数据。数据层一般都是传统数据库：Oracle、DB2等。
3、数据层通过JDBC等接口将结果数据传输给报表工具。
4、报表工具将接收到的数据，按照报表模板的样式生成可视化报表展现给用户。
上述这些报表处理过程中，网络、报表层和数据层的各个环节都有可能成为性能的瓶颈。
值得商榷的是，图1中“R2生成可视化报表”这个环节一般也会包含一些数据计算过程：从数据层返回的数据还要经过进一步加工才能满足报表的要求。特别是具备编程能力的报表工具，在这个环节也会消耗一些计算时间。例如：BIRT的自定义脚本、润乾报表的自定义数据集、格间计算。
因此，我们可以把这个环节分开，更有利于分析影响报表性能的因素。分开后如下图：
图2报表处理过程示意图（细分）
在图2中，标黄色的部分，是影响报表性能的主要因素。也就说，报表引擎对报表的解释和生成可视化报表的环节一般都不会成为性能问题的主要因素，最容易造成报表慢的，是数据计算和JDBC传输。因此，针对数据计算和JDBC传输所做的优化往往事半功倍。
划分好了报表处理的环节，需要分析一下图2中黄色部分造成性能问题的原因：
一、数据层“D1执行数据计算”环节。
在实际项目中，报表开发人员往往需要编写一些很长很复杂的SQL语句（或存储过程），来为报表计算数据。
报表开发人员会发现，使用SQL（或存储过程）实现复杂统计运算非常困难，特别是与序和集合有关的运算，如计算每月销售额都排进前10名的产品、连续五天上涨的股票等为报表准备数据的SQL过于复杂，可能长达数十行甚至数百行。
因为难以完整指定数据库的执行路径，所以复杂SQL执行起来一般都比较慢。报表开发人员想人工优化这些复杂SQL的时候也会发现很难入手。这是“D1执行数据计算”环节影响报表性能的主要因素。
例子：计算每个月的销售额都在前10名的客户。
select Client from(
select * from(
select B.*,row_number() over(partition by month order by SumValuedesc)
rown from(
selectto_char(SellDate,'mm') month,Client,sum(Quantity*Amount) SumValue
from contract
whereSellDate>=to_date('2012-01-01','yyyy-mm-dd')
andSellDate<=to_date('2012-12-31','yyyy-mm-dd')
group by to_char(SellDate,'mm'),Client order by month,client ) B
)C
whererown<=10
)D
group by Client
having count(Client)=(
select count(distinct(to_char(SellDate,'mm')))
from contract
whereSellDate>=to_date('2012-01-01','yyyy-mm-dd')
andSellDate<=to_date('2012-12-31','yyyy-mm-dd')
)
二、数据层“D2 JDBC传输数据”环节。
传统主流数据库提供的JDBC驱动在将数据流转换成Java对象时的效率很低，但又不可避开，在大量数据时就会感觉速度非常慢。虽然数据库的版本不断升级，但是这个问题一直都没有解决好。所以，对于较大源数据量报表来说，JDBC经常也是报表变慢的主要因素。
三、报表层“R2数据再次计算”环节。
1、很多报表工具会把“R2数据再次计算”和“R3生成可视化”两个环节一并处理，
数据计算的时候附带着很多显示属性（字体、颜色、格子大小等等），会一定程度上降低计算速度。
2、报表工具计算程序，一般是自定义函数、javascript或者java语言，并不提供完备的
关系数据计算类库，很多功能需要程序员自行编写实现。结果是：一方面程序员编写成本较高、时间较长；另一方面，也造成代码质量层次不齐，很难保证良好的性能。
3、报表工具不具备并行计算的能力，大数据量复杂任务无法拆成单机、多机的并行小
任务，很难有效的提高计算速度。
知道了造成这几个环节性呢过问题的原因，可以考虑如下几方面的优化：
一、数据层“D1执行数据计算”环节。
针对复杂SQL很难优化的问题，可以考虑计算能力增强的报表工具：润乾公司的集算报表。集算报表内置了集算器（esProc）是一个很好的过程化编程语言，其代码就更符合自然思维习惯，解决同样问题会比SQL短数倍。一方面，易于开发、调试和维护，降低了开发成本；另一方面，由程序员决定计算执行过程和路径，更易于提高计算性能。
每个月的销售额都在前10名的客户的例子用集算报表的esproc来实现就非常简明：
集算报表可以方便的接收A7单元格的计算结果，直接展示即可。
二、数据层“D2 JDBC传输数据”环节。
针对传统数据库JDBC传输缓慢的问题，可以考虑将较大规模的历史数据存在文件系统中。利用集算报表的esproc来访问文件系统中的数据，要比传统数据库的JDBC数据传输的速度快很多。集算报表访问esproc也是JDBC方式，但esproc是基于Java的，所以其JDBC 不需要再做数据流的对象转换，要比传统数据库快很多。而esproc也可以将计算结果直接返回给集算报表使用（非JDBC方式），彻底避免了数据库JDBC在对象转化时性能低下的情况。
另一个可以考虑的解决办法是，由于集算报表是展现和计算分离的，发挥esproc并行
计算的优势，用多个子程序通过不同的JDBC连接同时从数据库中取数。实际对oracle数据库的测试发现，16个并行任务同时取数的时候，速度可以提高十倍。考虑到数据库压力增加的问题，这个解决办法适用于数据库本身负载压力较小的情况。
三、报表层“R2数据再次计算”环节。
1、集算报表的esproc计算时不附带显示属性，有效提高计算速度。
2、集算报表的esproc具有关系数据计算的完备而且丰富的类库，提供了大量提高性能的优化选项。特别是与序和集合有关的运算，程序员可以有效利用数据在业务上的规律，控制执行路径，提高计算速度。
3、集算报表的esproc还具备并行计算能力，可以把大数据量复杂任务拆成多机的并行小任务，有效的提高计算速度。
注：具体的性能测试指标请参见esproc性能测试报告。