报表性能测试.doc

测试报告 帆软报表FineReport性能测试报告 目 录第一章 性能测试概述11.1 性能测试目的11.2 名词解释11.3 参考资料1第二章 测试需求分析12.1 测试目的12.2 测试对象12.3 系统结构22.4 测试属性22.4.1 测试范围22.4.2 主要检测内容22.5 系统环境22.5.1 硬件环境32.5.2 软件环境32.6 测试基础数据说明42.7测试指标说明5第三章 测试计划及方案53.1 测试场景设计53.1.1 单一用户，运算一张报表的性能53.1.2 多用户，运算同一张报表的性能63.1.3 大数据量报表的运算能力63.1.4超大数据量报表的运算能力63.1.5每秒处理事务TPS专题7第四章 单个用户，运算一张报表的性能74.1 一万数据量测试结果74.1.1不采用行式引擎及分页算法的报表展现74.1.2采用行式引擎及分页算法的报表展现94.1.3对比总结114.2 五万数据量测试结果124.2.1不采用行式引擎及分页算法的展现124.2.2采用行式引擎及分页算法的展现144.2.3对比总结164.3 十万数据量测试结果174.3.1不采用行式引擎及分页计算报表展现174.3.2采用行式引擎及分页计算报表展现194.3.3对比总结204.4 结果汇总21第五章 多用户，运算同一张报表的性能215.1 一万并发测试结果225.1.1不采用行式引擎及分页计算225.1.2采用行式引擎及分页计算235.1.3对比总结255.2 五万并发测试结果265.2.1不采用行式引擎及分页计算265.2.2采用行式引擎及分页计算275.2.3对比总结295.3 十万并发测试结果305.3.1不采用行式引擎及分页计算305.3.2采用行式引擎及分页计算315.3.3对比总结335.4结果汇总34第六章 大数据量报表的运算能力346.1 五十万单用户访问报表356.2五十万多用户访问报表376.3一百万单用户访问报表396.4一百万多用户访问报表416.5结果汇总43第七章 超大数据量报表的运算能力437.1单用户超大数据量报表447.2多用户超大数据量报表457.3结果汇总47第八章 持续访问TPS专题488.1不采用行式引擎及分页计算488.1.1单用户持续访问5分钟488.1.2十个用户持续访问5分钟498.1.3五十个用户持续访问5分钟518.2采用行式引擎及分页计算528.2.1单用户持续访问5分钟528.2.2十个用户持续访问5分钟548.2.3五十个用户558.3结果汇总57第九章 测试报告结论57第一章 性能测试概述1.1 性能测试目的随着企业信息化的全面推进，目前应用系统的大数据量运算、大并发等情况相当普遍，模拟实际系统使用环境进行针对报表的性能测试。编写此测试方案的目的是通过测试确认软件是否满足产品的性能需求，同时发现系统中存在的性能瓶颈，起到优化系统的目的。测试的依据是产品的需求规格说明书；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。此模板使用于性能测试的方案设计和测试报告记录。1.2 名词解释无1.3 参考资料此方案参考帆软报表产品相关文档。第二章 测试需求分析2.1 测试目的针对业务系统处理生成数据量较大，需要执行性能测试，得出系统的性能指标；另外，持续进行大压力测试，对系统进行稳定性测试。2.2 测试对象本次测试产品的名称，版本说明。Product Name：帆软报表 V6.5 2.3 系统结构2.4 测试属性2.4.1 测试范围报表系统各项性能指标，软件响应时间的性能测试、CPU、Memory的性能测试、负载的性能测试（压力测试）。2.4.2 主要检测内容1)典型应用的响应时间2)客户端、服务器的CPU、Memory使用情况3)服务器的响应速度4)系统支持的最优负载数量5)网络指标6)系统可靠性测试2.5 系统环境性能测试的软硬件环境说明。2.5.1 硬件环境测试应用服务器配置：应用服务器类型IPCPUOSMemoryStorageTomcat5.070Intel(R) Core(TM)2 Quad CPU Q8300 2.50GHz 2.51GHzWindows Server 20031G1TB报表所用服务器为报表内置的Tomcat服务器。测试数据库服务器配置数据库类型IPCPUOSMemoryStorageOracle10g68Intel(R) Core(TM)2 Quad CPU Q9550 2.83GHz 2.83GHzWindows Server 20031G1TB2.5.2 软件环境 测试软件产品帆软报表 V6.5版本 测试工具Mercury LoadRunner 8.1LoadRunner 概要介绍：LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。模拟图如下：2.6 测试基础数据说明为了能够测试在并发及大数据量下的性能表现，通过数据复制的方式准备了如下测试数据：表名称：TableTenm （数据记录数：10万条）名称类型是否可空是否主键个人编号NUMBERNOYES单位编号VARCHAR2(20)NONO单位地址VARCHAR2(20)NONO参保时间VARCHAR2(20)NONO缴费金额VARCHAR2(20)NONO生日VARCHAR2(20)NONO性别VARCHAR2(4)NONO缴费状态VARCHAR2(10)NONO2.7测试指标说明在总体性能测试情况概要中有这样3个指标：Average Throughout(bytes/second)，表示每秒的吞吐量，即服务器跟浏览器之间传输每秒的字节数，这个数值越大，就说明性能越好；Average Hits per Second：每秒钟的点击数，这里的点击数就是HTTP协议每秒钟发出的请求数，这个指标可以表明对服务器的压力，发出的请求数越多对服务器的压力就越大。当然，这些参数的比较都是在相同环境下比较才有意义的；Transactions per Second：每秒处理的事务数目，一般处理的事务数是Controller执行的在脚本里录制的时候以初始化和结束事件为标记的个数，一个事务对应多个点击，例如在一个事务中，对应的网页中链接有图片，图片对应会发送一个点击，因此，一个事务可能会有多个点击，这是事务数跟点击率的一个简单关系。其他两个指标是报表执行时间跟系统资源消耗，系统资源消耗这里引用process time参数作为指标，为CPU利用率。以下测试过程都分为四个环节分析指标的数值，第一：总体性能概要；第二：报表展示时间；第三：CPU利用率；第四：事务处理（针对并发）。第三章 测试计划及方案3.1 测试场景设计正常企业的实际生产环境中，大数据量非常常见。数据量过大，往往导致运算速度非常慢，客户端等待时间过长，甚至导致服务器内存溢出等等现象。比如在银行、税务、商业等领域都有包含大数据量的报表。在木桶原理的作用下，这些大数据量的报表通常都是业务系统的瓶颈，决定着一个业务系统的成功与失败。通过测试大数据量的报表，可以在更早的评估出一个报表工具是否适合将来实际的生产环境。那么，从性能方面，要解决的问题包括以下三个层面场景，每个层面下面分为是否执行行式引擎和分页计算两种优化方式，行式引擎跟分页计算两种引擎同时使用可以很大程度上加快报表访问速率，使得在报表展现更加人性化。3.1.1 单一用户，运算一张报表的性能说明：单一用户，运算一张报表的性能是考核报表工具引擎性能优化及运算能力的硬指标。一般来说，如果不采取任何措施，如分页计算、缓存、并发控制、调度等，在java堆为2048M内存的情况下，运算一张报表的硬指标在10万条记录以下基本足够，数据量再大基本就会采取各种措施了。另外，单一用户，在实际应用环境下，等待时间不应超过1分钟，而超过5分钟就会认为系统死机，迫切地期望中断运行。因此，报表工具对于如何减少等待时间、是否提供中断大报表运行的能力非常重要。这种能力可以直接提升用户的体验感觉。值得关注的是，运算一张报表的性能，不仅仅要考核简单线性报表，还需要考核复杂的非线性报表；不仅仅要考核运算速度，还需要考核能够支持的最大数据量，应当是综合得分。单一用户需要再分为是否执行行式引擎和分页计算。3.1.2 多用户，运算同一张报表的性能说明：多用户并发的时候，常常出现多个用户访问同一张报表，此次测试不采取任何缓存措施，测试支撑并发访问的能力。多用户下再分为是否执行行式引擎和分页计算。3.1.3 大数据量报表的运算能力在2048m内存下，我们认为50万，100万条记录的报表可以归入大数据量报表的范畴。此时用户更加看重的是能否采取有效机制使得大数据量报表正确运算出来，且每一页的展现时间很短，不需要长时间等待。大数据量的报表就很必要选择执行行式引擎和分页计算，这样会大大提高报表展现速度。3.1.4超大数据量报表的运算能力100万数据量的称为大量数据量报表，那1000万数据量的报表就可以称得上是超大型的了，不采用优化引擎执行速度可想而知，这里就测试一下采用引擎之后的性能，分单用户跟多用户两种情况。3.1.5每秒处理事务TPS专题由于TPS是体现服务器处理事务的能力的一个重要指标，体现了每秒服务器能处理的事务的个数，因此单独列出专题，采用持续5分钟访问报表来进行测试，大量的发送请求才能更好的了解服务器的性能。第四章 单个用户，运算一张报表的性能4.1 一万数据量测试结果4.1.1不采用行式引擎及分页算法的报表展现1）总体性能测试情况概要2）报表展现时间3）系统资源消耗CPU利用率为上图中的绿点对应的坐标值：23%4.1.2采用行式引擎及分页算法的报表展现1）总体性能测试情况概要2）报表展现时间3）系统资源消耗CPU利用率为25%。4.1.3对比总结通过参数说明中对各个参数的理解，从以上测试结果可以看出，在处理1万条数据的时候，由于在简单列表展示性能上的优越性，一万数据的列表只需要很短的时间，添加行式引擎跟不添加的效果几乎没有什么区别。如下图所示：4.2 五万数据量测试结果4.2.1不采用行式引擎及分页算法的展现1）总体性能测试情况概要2）报表展现时间3）系统资源消耗CPU利用率为25%。4.2.2采用行式引擎及分页算法的展现1）总体性能测试情况概要2）报表展现时间3）系统资源消耗CPU利用率为25%。4.2.3对比总结通过参数说明中对各个参数的理解，从以上测试结果可以看出，在处理5万条数据的时候，添加行式引擎之后的执行速率会得到明显提升。如下图所示：4.3 十万数据量测试结果4.3.1不采用行式引擎及分页计算报表展现1）总体性能测试情况概要：上图是测试过程的一个总结性的数据统计，这里主要的参数是Average Throughput(byte/second)：每秒的吞吐量，这个数据越大也就说明了访问速度比较快。Hit Per Second：每秒点击量，是每秒钟用户给服务器发送的HTTP请求数，来体现对服务器压力的大小。2）报表展现时间：从上图中可以看出，上述环境下，一个用户运行一张10万行数据量的报表所需要的时间为39秒。3）服务器系统资源消耗：系统资源中有很多参数，我们在此选择最能说明问题的Resource Usage：资源占用率，来体现性能，可以看到资源占用率平均不到50%。4.3.2采用行式引擎及分页计算报表展现1）总体性能测试情况概要2）报表展现时间3）系统资源消耗4.3.3对比总结由以上测试结果表明，行式引擎提高了报表运算时间，占用cpu平均时间也降低的不少。结果如下图：4.4 结果汇总由以上结果汇总如下：首先，这样的列表一万数据量采用不采用行式引擎效果不是很明显，因为本身就已经很快了。采用行式引擎及分页计算之后，不管是展示时间还是在系统消耗方面，还是会看到一个明显的优化；第五章 多用户，运算同一张报表的性能上面的章节是针对单个用户运算一张常规大数据量报表的性能测试计划，如果多个线程重复访问同一张报表，这就需要模拟测试多用户对服务器的压力测试报表性能。下面我们仍采用上面几章节所用的1万，5万跟10万行数据量的报表模板，测试多用户下的性能。此次测试不采取任何缓存措施，测试支撑并发访问的能力。这里将并发数设置为100，并且设置为100虚拟用户同时访问Web报表。5.1 一万并发测试结果5.1.1不采用行式引擎及分页计算1）总体性能测试概要2）报表展现时间3）服务器系统消耗资源CPU利用率60%4）每秒处理事务数TPS总共100个事务，如上图所示，是整个过程中每秒处理的平均值。5.1.2采用行式引擎及分页计算1）总体性能测试概要2）报表展现时间3）服务器系统消耗资源CPU利用率为59%。4）每秒处理事务数TPS总共100个事务，如上图所示，是整个过程中每秒处理的平均值。5.1.3对比总结由以上结果汇总如下图所示：执行报表时间也有了一个降低。5.2 五万并发测试结果5.2.1不采用行式引擎及分页计算1）总体性能测试概要2）报表展现时间3）服务器系统消耗资源CPU利用率48%。4）每秒处理事务数TPS总共100个事务，如上图所示，是整个过程中每秒处理的平均值。5.2.2采用行式引擎及分页计算1）总体性能测试概要2）报表展现时间3）服务器系统消耗资源CPU利用率为47%。4）每秒处理事务数TPS总共100个事务，如上图所示，是整个过程中每秒处理的平均值。5.2.3对比总结五万数据的并发结果汇总如下图所示：5.3 十万并发测试结果5.3.1不采用行式引擎及分页计算1）总体性能测试情况概要：2）报表展现时间：3）服务器系统资源消耗：CPU利用率为52%。4）每秒处理事务数TPS总共100个事务，如上图所示，是整个过程中每秒处理的平均值。5.3.2采用行式引擎及分页计算1）总体性能测试概要2）报表展现时间3）服务器系统消耗资源CPU利用率为47%。4）每秒处理事务数TPS总共100个事务，如上图所示，是整个过程中每秒处理的平均值。5.3.3对比总结汇总结果如下图：访问时间减少了不少。5.4结果汇总不同数据量的并发测试结果如下图所示：由上图可见，采用行式引擎及分页计算，必然会提升报表生成速度。第六章 大数据量报表的运算能力在2048m内存的配置下，我们认为50万，100万条记录的报表就属于大数据量报表了，因此需要采用分页计算和分页输出。下面是分别访问50万跟100万条记录的报表测试结果。下面是一张50万数据表的预览：6.1 五十万单用户访问报表1）总体性能测试概要2）报表展现时间3）系统资源消耗CPU利用率为34%6.2五十万多用户访问报表1）总体性能测试概要2）报表展现时间3）系统资源消耗CPU利用率为74%。4）每秒处理事务TPS总共100个事务，如上图所示是每秒平均处理的事务数。6.3一百万单用户访问报表以下是一百万报表的预览1）总体性能测试概要2）报表展示时间3）系统资源消耗CPU利用率为30%6.4一百万多用户访问报表1）总体性能概要2）报表展示时间3）系统资源消耗CPU利用率为60%4）每秒处理事务数TPS总共100个事务，如上图所示，是每秒平均处理事务的个数。6.5结果汇总总结以上数据：在处理大数据量的报表的时候，使用行式引擎的情况下，即使是100的并发，所花费的时间也不会太多，如上结果显示，也只需要十几秒而已，因此在上述数量级上的报表很有必要采用行式引擎及分页计算。第七章 超大数据量报表的运算能力对于一些千万级的数据库或者更大的，我们称之为超大型数据库，为了提高运算效率跟展示速度，采用行式引擎及分页计算势在必行，以下测试过程中都会设置采用引擎进行优化。以下以一张1000万数据量的报表为例：7.1单用户超大数据量报表1）总体性能测试概要2）报表展现时间3）系统资源消耗CPU利用率为31%7.2多用户超大数据量报表1）总体性能测试概要2）报表展现时间3）系统资源消耗CPU利用率为38%4）每秒处理事务数TPS总共100个事务，如上图所示，是每秒平均处理事务的个数。7.3结果汇总对于一千万的数据量都采用了行式引擎，不采用行式引擎访问速度显然是无法接受的。由以上数据汇总如下：由上图可以看到，在千万级数据量的报表上设置引擎优化，展示的时间可以得到很大程度上的优化，一百并发用时不到一分钟。第八章 持续访问TPS专题以上事务数比较少，最多不超过100，不足以说明服务器处理事务的能力，在这个专题中，我们以一万数据为例，分别一个用户，10个用户，50个用户连续访问5分钟，来检测TPS指标，根据LR绘制的曲线来分析服务器的处理能力。8.1不采