润乾报表与集算报表的计算性能对比测试

1、测试目的

在相同的硬件和web容器上测试润乾报表和集算报表的性能,对比在报表中完成分组、排序、过滤、连接、排名的性能差异,以及并发情况下二者的表现。测试过程中,润乾报表将采用报表工具内置的计算引擎,集算报表采用其内置的集算器计算引擎。


2、环境描述

测试机型:DellInspiron 3420

CPU:Intel Core [email protected] *4

RAM:4G

HDD:西数WDC(500G5400转/分)

操作系统:Win7(X64)SP1

JDK:1.6

数据库:oracle11gR2

Tomcat6.0.36_x64

TomcatJVM内存:-Xms512m-Xmx2048m

润乾报表版本:4.5.6

集算报表版本:5.0

3、数据描述

测试使用到三个表T1、T2、T3,下表为三表信息,其中数据量为记录条数。

T1、T2表结构相同,如下:

T3表结构:

4、用例描述

4.1分组

使用T2表,在报表中分别按照Date2和Date字段进行分组,进行分组汇总,取数sql:

ds1: select * from t2.

报表格式为:

4.1.1  润乾报表实现

4.1.2 集算报表实现

集算器脚本

报表模板

4.2    排序

使用T1表,取50万条记录,在报表按照Date字段进行排序,报表显示5个字段,取数sql:

ds1:select * from t1 where rownum<500000。

报表格式为:

4.2.1 润乾报表实现

4.2.2集算报表实现

集算器脚本:

报表模板:

4.3 过滤

使用T1表,在报表中按照ID字段过滤,过滤后数据量为82条,取数sql:

ds1:select * from t1.

报表格式为:

4.3.1  润乾报表实现

4.3.2 集算报表实现

集算器脚本

报表模板:

4.4   连接

使用T2和T3表,在报表中按照T2的ID字段与T3左连接,取数sql:

ds1:select * from t2 where userid<267427523

ds2:select * from t3 where userid<10485202

ds1记录数为:7171;ds2记录数为:12730

报表格式为:

4.4.1 润乾报表实现

4.4.2 集算报表实现

集算器脚本:

报表模板:

4.5   排名

使用T3表,在报表中根据SumTime进行排名,取数sql:

ds1: select * from t3 whereuserid<8883948

数据集ds1记录数为:10430。

报表格式为:

4.5.1 润乾报表实现

4.5.2集算报表实现

集算器脚本:

报表模板:

4.6并发分组

使用5.1分组用例,进行多并发分组测试,这里采用4个并发。

5、测试方法

使用两个完全相同的Tomcat(JVM等完全)分别部署润乾报表应用和集算报表应用,报表数据来源相同,润乾报表使用sql数据集,直接取数;集算报表采用集算器数据集,取数在dfx中完成。分别比较报表中完成的分组、排序等报表性能,每个用例测试时前均重启Tomcat,以保证无其他报表占用内存等资源。

此外,由于测试机配置,不同用例使用了不同数据表,故不同用例之间纵向无可比性,主要看横向,即:润乾报表和集算报表的性能差异。

6、测试结果

*下表结果数据单位为:秒


【说明】

这里的时间记录是从SQL取数完毕后到报表计算完成,润乾报表的日志中会直接提供这两个时间点,相减即得间隔时间;集算报表需要在脚本中加debug信息记录取完数的时刻,再与报表日志中的计算完报表的时间相比,得到间隔时间。

7、解读分析

集算报表将计算放在集算器脚本中进行,集算器采用了更高效的Hash算法,对于分组等有数据关联的计算有极其显著地提高,对于过滤排序等硬遍历式计算则在算法层面没有较大提升,表现出来的少量提高主要是因为集算器中运算不带有展现属性造成的。

这次测试的所有运算都是单线程的,事实上,集算器还可以支持多线程并行计算以充分利用CPU的多核,还能进一步提升性能,即使在排序和过滤类的运算上也能有数倍提高。而包括润乾报表在内的大部分报表工具目前都不支持多线程并行计算,无法利用CPU的多核提高性能。

润乾报表与集算报表的计算性能对比测试

时间: 2024-10-19 08:13:09

润乾报表与集算报表的计算性能对比测试的相关文章

润乾报表教程-集算报表优化计算过程

报表作为数据统计分析软件,当它出现性能问题需要对数据源计算进行优化时,执行路径难以控制是阻碍报表优化的难题之一.这是由于数据库执行路径不透明,程序员很难甚至无法干预执行路径,也就难以提高数据库的性能.而一般报表工具不具备强计算能力,大部分计算仍然要依靠数据库进行,这就导致很多报表优化效果不理想. 不同于一般报表工具,润乾集算报表内置了专门用于数据计算的集算引擎,开发人员可以通过编写集算脚本完成报表数据源准备.与数据库执行SQL路径不可控相比,集算脚本的执行过程是可控的,开发人员可根据实际情况编写

润乾集算报表应用开发之参数输入

参数对于报表的重要性不言自明,润乾集算报表支持两种参数输入方案,可以使用集算报表设计参数模板联合报表一同发布,还可以自定义参数输入后与报表结合.二者并没有显著的差异,前者在开发使用上更加方便快捷,而后者则在灵活性上更胜一筹,用户在使用集算报表参数输入时可以根据实际需要进行选择. 下面就上述两种参数输入方式的使用分别来看一下. 使用参数输入模板 集算报表提供了"参数模板"的报表类型,使用参数模板可以制作参数输入表单,而且其内置了多种编辑风格,如下拉树.下拉日历.列表框.下拉数据集等.使用

用润乾集算报表提升性能之关联计算

报表开发过程中经常要在报表中完成数据关联计算,有的为了降低报表制作复杂度将关联关系放到可视的报表模板中完成:有的则必须在报表中完成关联,如多数据源.异构数据源的情况.而在报表中做关联往往导致报表效率不高,计算过慢,引发性能问题.润乾集算报表提供了特殊的数据关联方式,可以提升报表性能.这里通过一个常见的多源关联分片报表实例来看一下集算报表的实现过程:     报表说明 根据销售情况等信息表按照时间.地区.销售人员.产品等维度汇总销售额,报表样式如下: 以下为实现过程.     编写计算脚本 首先使

集算报表与润乾报表处理动态报表时的异同

集算报表继承了润乾报表的宏机制来处理动态报表,对于简单的动态报表使用宏实现非常方便.对于一些复杂的动态报表,集算报表还提供了脚本数据集来处理动态报表,适合宏无法实现的场景,而润乾报表中要实现复杂动态报表时则需要编写自定义数据集来完成.下面通过几个例子来详细比较一下集算报表和润乾报表在处理动态报表时的相同与不同点. 相同点 集算报表和润乾报表都提供了宏,使用方式几乎完全一致,且都包含普通宏和动态宏.         普通宏常用于静态内容替换,如在员工表中同时只希望查看薪金或奖金,开发两张报表显然是

集算报表与润乾报表的计算性能对比测试

1.测试目的 在相同的硬件和web容器上测试润乾报表和集算报表的性能,对比在报表中完成分组.排序.过滤.连接.排名的性能差异,以及并发情况下二者的表现.测试过程中,润乾报表将采用报表工具内置的计算引擎,集算报表采用其内置的集算器计算引擎. 2.环境描述         测试机型:DellInspiron 3420         CPU:Intel Core [email protected] *4         RAM:4G         HDD:西数WDC(500G5400转/分)  

润乾集算报表非常规统计之按段分组

报表开发中,经常会碰到一些需要进行非常规统计的报表,固定分组.可重复分组.组内排序,还包括跨行组计算的报表,甚至有些报表本身无数据来源.以及需要对数据源再计算.这些报表本身具备一定的特殊性,使用常规方法往往难于实现. 对于按段分组报表,各段之间可以有重复,也就可能出现按段可重复的分组报表.集算报表在完成这类特殊统计报表时比较简单,这里通过一个实例说明实现过程. 报表说明 根据员工基本信息表按年龄统计各年龄段区间的人数.奖金等汇总情况.报表样式如下: 这里"30-40岁"和"3

润乾集算报表提升性能之预先计算

报表应用中当数据量较大或计算过程较复杂时,会导致报表数据源准备过慢,从而影响报表性能.这时常常需要事先将报表需要的数据计算好,在呈现时直接引用即可,这样用户在访问报表时就可以迅速地获得响应. 当前的手段及弊端 由于报表在访问时还需要参数,显然不可能把所有参数组合对应的报表数据源都准备好,所以预先计算并不是最终的报表结果,在呈现的时刻仍然要再次进行一些简单的计算(如过滤.分组汇总.排序等),然而也不太可能指望报表呈现时刻由报表工具再完成所有这些运算(报表工具只能完成一部分小数据量的运算),这样就要

润乾集算报表使用远程HTTP数据源的示例

报表的数据来源多种多样,有时会接收来自HTTP服务器的数据进行报表展现,一般报表工具只能通过报表自定义数据源使用高级语言(如JAVA)进行处理,实现较为复杂.集算报表简单地通用集算器接收HTTP数据源完成报表展现.这里通过一个实例说明. 学生成绩信息存储在远程的JSON格式文件中,其所在HTTP服务器对外提供统一HTTP访问接口,现需要读取学生成绩信息开发报表,汇总学生成绩并按总成绩排名.报表样式如下: JSON文件中包含班级.编号.姓名.学科.成绩等信息,格式如下: [ { "class&qu

用润乾集算报表实现实时报表(T+0)的方案

在报表项目中,客户越来越关注源数据的实时性,希望看到最新发生的数据在报表中体现出来.但是,传统的报表工具+数据仓库+ETL方式很难做到这一点,往往是只能看到昨天.上周甚至是上个月的情况,也就是T+1.T+7.T+30统称T+n报表.很难实现T+0报表,也就是能体现实时信息的报表. 分析其原因在于:1.如果报表的历史数据和最新数据都从客户的生产系统读取,虽然可以实现T+0报表,但是会对生产数据库造成压力,影响客户的业务.2.如果采用数据仓库的方式,那么ETL从生产库中取出数据,需要较长的"窗口时间