测试目的:
考虑到各地区的用户数量和单据量的增加会给服务器造成的压力不可估计,为确保TMS系统顺利在各地区推广上线,决定对TMS系统进行性能测试,重点为监控服务器在并发操作是的资源使用情况和请求响应时间。
测试内容
测试工具
主要测试工具为:LoadRunner11
辅助软件:截图工具、Word
测试结果及分析
5个用户同时生成派车单的测试结果如下:
Transaction Summary(事务摘要)
从上面的结果我们可以看到该脚本运行47秒,当5个用户同时点击生成派车单时,系统的响应时间为41.45秒,因为没有设置持续运行时间,所以这里我们取的响应时间为90percent –time,且运行的事物已经全部通过
事务概论图,该图表示本次场景共5个事务(每个用户点击一次生成派车单为1个事务),且5个事务均已pass,绿色表色pass,如出现红色则表示产生error
系统资源
从上图可以看到服务器的CPU平均值为14.419% ,离最大参考值90%相差甚远;且趋势基本成一直线状,表示服务器响应较为稳定,5个用户操作5个900托运单的单据对服务器并没有产生过大的压力。
每秒点击数
“Hits per Second(每秒点击数)”反映了客户端每秒钟向服务器端提交的请求数量,这里服务器每秒响应9,771次请求;如果客户端发出的请求数量越多,与之相对的“Average Throughput (吞吐量)”也应该越大。图中可以看出,两种图形的曲线都正常并且几乎重合,说明服务器能及时的接受客户端的请求,并能够返回结果。
按照上述策略,我们得出的最终测试结果为:
生成派车单:
1个用户,300个托运单点击生成派车单,响应时间7.34秒
5个用户,900个托运单点击生成派车单,响应时间41.45秒
单据匹配:
单用户1000箱,20000个商品,上传匹配时间8秒
五个用户2500箱,40000个商品,同时上传匹配耗时2分25秒
自由派车:
单条线路917个托运单下载,响应时间1分40秒
上述结果是在公司内网,测试环境上进行的测试,可能与实际会有偏差
同时本次压测过程发现了3个bug
BUG#25680 【测试环境-1.0.5】五个用户,每个用户同时上传500个单据时,系统报异常(提示用户请求取消当前操作) --待修复
BUG#25519【1.0.5】RF装车界面,当待装车明细过大(超过20000箱)时,点击明细按钮会导致RF崩溃,且明细数量也不正确!--已发版待验证
BUG#25545 【测试环境-1.0.4】PC创建派车计划,多个用户同时选择同条线路,可以选到同样的托运单并审核成功。 --待修复
结论
本次性能测试得出的结果具有一定参考价值,用户数量和数据量也比较切进现场实际情况,所得的各项响应时间在用户可接受的范围,因此本次性能测试通过。
第二篇:数据库性能测试报告
数据库性能测试报告 编制人:小生
数据库系统性能测试报告
数据库性能测试报告
数据库性能测试报告 编制人:小生
目录
1计划概述 ........................................................................................................................................................ 3
2参考资料 ........................................................................................................................................................ 3
3术语解释 ........................................................................................................................................................ 3
4系统简介 ........................................................................................................................................................ 3
5测试环境 ........................................................................................................................................................ 3
6测试指标 ........................................................................................................................................................ 4
7测试工具和测试策略 .................................................................................................................................... 4
8测试数据收集 ................................................................................................................................................ 4
9测试结果数据以及截图 ................................................................................................................................ 4
10 测试结论 ................................................................................................................................................... 10
数据库性能测试报告
数据库性能测试报告 编制人:小生 1计划概述
目的:找出系统潜在的性能缺陷
目标:从安全,可靠,稳定的角度出发,找出性能缺陷,并且找出系统最佳承受并发用户数,以及并发用户数下长时间运行的负载情况,如要并发100用户,如何对系统进行调优
概述:本次测试计划主要收集分析数据库处理并发请求相关数据,做出分析和调优
测试时间:*年*月**日 *点*分-*点*分
2参考资料
相关性能测试资料
3术语解释
性能测试
英文解释:Performance testing 概念解释:运行性能测试确定系统处理能力,来判断系统是否需要优化
负载测试
英文解释:Load testing
概念解释:通过系统面临多资源运行或被攻击情况下进行测试
4系统简介
数据库服务器,支持整个系统对数据的存储过程
5测试环境
数据库性能测试报告
数据库性能测试报告 编制人:小生 6测试指标
测试时间:*年*月*日—*年*月*日
测试范围:数据库处理服务器或客户端请求信息(插入,查询,更新,删除)语句时,服务器各项性能指标的性能测试
Jmeter指标:(由于Apache旗下性能测试工具Jmeter收集的性能指标偏少,下面的数据选取代表性指标)
1.Average/ms:服务器处理事物平均响应时间(表示客户端请求到服务器处理信息且反馈客户端的时间)
2.Throughput/s:服务器每秒处理请求数(表示服务器每秒处理客户端请求数(单位:个/秒))
3.KB/s:服务器每秒接受到的数据流量(表示服务器每秒接受到客户端请求的数据量KB表示) 硬件指标:
1.%Processor time : CUP使用率(平均低于75%,低于50%更佳)
2.System:Processor Queue Length :CUP队列中的线程数(每个处理器平均低于2)
3.Memory:Pages/sec :内存错误页数(平均低于20,低于15更佳)
4.Physical Disk-%Disk Time: 磁盘使用率(平均低于50%)
5.SQL Server:Buffer Manager-Buffer Cache Hit Ratio: (在缓冲区告诉缓存中找到而不需要从磁盘中读取的页的百分比,正常情况次比率超过90%,理想状态接近99%)
7测试工具和测试策略
? 测试工具:Apache-Jmeter2.3.2
? 测试策略:根据公司内部实际情况,以及业务分布设置数据库访问量即并发用户数
? 测试数据:因为涉及公司内部数据不便外泄,敬请见谅!
? 数据说明:选取数据均为代表性数据,包括存储过程以及查询,更新,删除,插入
8测试数据收集
收集多轮测试的结果进行对比,绘制成几何增长图形,找出压力转折点
9测试结果数据以及截图
前提条件:用户数为80个用户数时,并发访问数据库,发生错误,所以最佳用户定在75个
数据库性能测试报告
数据库性能测试报告 编制人:小生
9.1Jmeter性能指标
Average/ms
? 数据分析:
本图表示服务器处理请求的平均相应时间,
最佳性能是随着并发用户数的增加,平均事物响应时间比较平缓。
本图清晰可以看到,随着并发用户数的增加事物响应也随着上升,
数据库性能测试报告
数据库性能测试报告 编制人:小生
Throughput/s
? 数据分析:
本图表示服务器每秒处理请求个数
最佳性能服务器处理处理请求数是随着用户的增加而增加
本图可以直观看到服务器处理请求数的个数并未随着用户数的增加而增加
KB/S
数据库性能测试报告
数据库性能测试报告 编制人:小生
数据库分析:
? 本图为服务器每秒接受到的数据流量
? 最佳或理想状态下,服务器接受到的数据流量一定是随着用户数的增加而上升
? 上图使用折线视图清晰表明当用户数增加的同时服务器接受的请求数据流量并未上升
请求总数与用户数图
数据库分析:
? 上图明显看出5-15个用户数发起请求时,总请求数比较高而且平缓
? 当在25-30之后的请求总数与并发用户数的不成比例
? 反而随着并发用户数的增加,总请求数在下降!
数据库性能测试报告
数据库性能测试报告 编制人:小生
9.2硬件指标图
下图为75并发用户数发起请求服务器硬件信息监控图
数据库性能测试报告
数据库性能测试报告 编制人:小生
? 数据分析:
上图直观表现出内存错误页数平均值在20,峰值高达1300(蓝线)
正常平均数据为20以下,15以下更佳
下图为50并发用户数发起请求服务器硬件信息监控图
数据库性能测试报告
数据库性能测试报告 编制人:小生
数据分析:
? 上图直观表现出内存错误页数平均值在20,峰值高达1300(蓝线)
? 正常平均数据为20以下,15以下更佳
备注:(更多硬件指标图请到192.168.1.***机器下F:\jmeter report\jmeter 中察看 )
10 测试结论
Jmeter性能指标分析
? 由Jmeter性能指标最直观的可以看出时网络性能的不足
客观的可以反映出服务器处理能力存在优化空间
? 优化建议:增加网络速度(增加宽带兆数)
? 3.5服务器可以承受75个用户同时并发访问,但是,本次测试不代表服务器负载能力
服务器硬件信息监控数据分析
? 结合Jmeter性能指标和多个硬件监控图得出内存是服务器瓶颈之一
数据库性能测试报告
数据库性能测试报告 编制人:小生 ? 优化建议:提高内存质量,更换更大内存以提高内存处理能力
数据库性能测试报告