收藏 分享(赏)

性能测试报告.docx

上传人:weiwoduzun 文档编号:3733907 上传时间:2018-11-17 格式:DOCX 页数:19 大小:365.11KB
下载 相关 举报
性能测试报告.docx_第1页
第1页 / 共19页
性能测试报告.docx_第2页
第2页 / 共19页
性能测试报告.docx_第3页
第3页 / 共19页
性能测试报告.docx_第4页
第4页 / 共19页
性能测试报告.docx_第5页
第5页 / 共19页
点击查看更多>>
资源描述

1、接口性能测试报告Rev:A.1编制 软件测试工程师 * 日期批准 架构师 * 日期Page ( 2 ) of ( 19 )目录1. 概述 .31.1 目的 31.2 术语 31.3 参考资料 3第 1 章 需求分析 .42. 项目背景 52.1 部署结构图 62.2 系统架构图 63. 测试资源 83.1 测试环境 83.2 人力资源 93.3 测试工具 10(1)Jemeter 工具介绍 10(2)工作原理 .10(4)Jmeter 图表指标说明 11(3)JVM 监控工具 .11(4)服务器资源监控工具 114. 测试策略 .124.1 测试目标 .124.2 测试方法 .124.3 测试

2、内容 .134.4 缺陷处理规范 .154.5 测试产物 .165. 测试计划 .18Page ( 3 ) of ( 19 )6. 风险分析 .19Page ( 4 ) of ( 19 )1 概述1. 1 目的该文档详细描述压力测试过程、测试监控数据以及测试数据分析结论。1.2 术语负载测试: 通过测试工具不断增大压力,查看系统性能表现的一个测试过程。负载机:发送请求,生产测试压力的机器。1.3 参考资料Page ( 5 ) of ( 19 )2. 测试需求2.1 被测系统分析*是一个试点项目,*正在接入到*项目中来,通过* 系统可以直接进入到*平台。后续用户量会随着*系统用户的接入逐渐增大。

3、11 月*系统会展示到互联网大会上 0,预计互联网大会访问量会到达一万以上,这么大的用户访问量必然对我们的系统造成很大的考验。当前*部署在一台 2 核 4G 的阿里云服务器上,在这样低的性能机器上系统能处理很大的并发是不可能的。目前系统注册和使用用户非常少,并不会对系统造成威胁。但是系统的处理效率、容量和稳定性未经过验证,还不确定系统在单服务器的效率、容量和稳定性。2.2 测试通过标准通过指标错误率 SubStringNumber of Simulated to Groupby 件 件 件Timeout 3000(3s)Connect timeOut 10000(10s)Response ti

4、meOut 10000(10s)Content encoding utf-8Lisener 件件 件 件 件 -l 件 件 csv件 件 件 件 件timeStamp,elapsed,label,responseCode,responseMessage,threadName,success,failureMessage,bytes,sentBytes,grpThreads,allThreads,Latency,IdleTime,ConnectSynchronizing Timer件 件 件HTTP件 件 件 件 件件 件 件 件 件3.6 测试监控(1) 应用服务器监控:使用 linux 自带

5、的 top、vmstat 命令监控服务器资源Page ( 8 ) of ( 19 )(2) Tomcat 的 JVM 监控:使用 jdk 自带的 jmap、jstat 查看内存、线程、类的情况。(3) 数据库监控:没有做监控。后续可以增加慢查询的跟踪。(4) 负载机监控:使用 linux 自带的 top、vmstat 命令监控服务器资源备注:由于是生产环境,所以没有使用第三方工具进行监控。Page ( 9 ) of ( 19 )4. 测试场景设计4.1 测试场景序 号 测 试 场 景 并 发 数 备 注2 用 100个 并 发 压 测 综 合 业 务 , 每 个 业 务分 配 25个 并 发

6、, 循 环 压 测 20次 100 验 证 脚 本 的 正 确 性3 用 200个 并 发 压 测 综 合 业 务 , 每 个 业 务分 配 50个 并 发 , 循 环 压 测 20次 200 翻 倍 增 大 并 发 , 检 验 系 统 的 性 能6 用 500个 并 发 压 测 综 合 业 务 , 每 个 业 务分 配 125个 并 发 , 循 环 压 测 20次 500 增 大 到 500并 发 , 检 验 系 统 的 性 能4 用 300个 并 发 压 测 综 合 业 务 , 每 个 业 务分 配 75个 并 发 , 循 环 压 测 20次 300 减 小 并 发 , 检 验 系 统 的

7、 性 能 超 时 率 是 否 有 减 少5 用 400个 并 发 压 测 综 合 业 务 , 每 个 业 务分 配 100个 并 发 , 循 环 压 测 20次 400 增 大 并 发 , 检 验 系 统 的 性 能7 从 20个 并 发 开 始 测 试 , 每 隔 10s钟 增 加20个 并 发 , 逐 渐 增 大 到 1000个 并 发 ,并 持 续 压 测 5分 钟 。 1000 从 0逐 渐 增 大 到 1000, 检 验 系 统 随 着 并 发 的 增 大系 统 的 处 理 效 率 是 一 个 什 么 样 的 反 应 。压 测 场 景由 于 超 时 率 高 与 预期 , 需 要 降

8、低 并 发 压测 , 压 测 过 程 中 增 加这 三 个 场 景 。4.2 相关业务接口4.3 测试用例从*入口进入*首页、商家详情页、商品详情页、商品列表、商家列表四个业务同时压测,每个业务相关的接口按列表中的顺序逐一请求。Page ( 10 ) of ( 19 )5.测试过程整个测试过程中5.1 100 个并发测试情况整个测试过程不管是错误率还是响应时间都是正常,系统响应很快,基本上小于400ms。5.2 200 个并发测试情况翻倍增加了并发数后,系统的响应有较大幅度的变厉害,部分接口响应时间翻倍,但是整个过程中平均响应时间小于 2s,TPS (如图 4)有所增长,达到预定指标。Page

9、 ( 11 ) of ( 19 )5.3 500 个并发测试情况继续增大并发量,翻倍增加了并发数后,系统整体的性能变化很大 TPS 和流量吞吐量都没有什么增长,系统的响应时间从原来小于 2s 到现在 2s10s 之间,超时率达到了4.43%。说明系统处理效率已经达到了瓶颈。继续减小并发查看系统的表现。Page ( 12 ) of ( 19 )5.4 300 个并发测试情况减少到 300 个并发后,系统的响应时间、tps、流量吞吐量都跟 200 个并发差不多。继续增大并发查看系统性能表现。Page ( 13 ) of ( 19 )5.5 400 个并发测试情况增大到 400 个并发后,系统响应时

10、间有所增大,比 300 个并发慢 23s。TPS 比 300个稍大,流量吞吐量没什么大的变化。系统还是处理比较正常的。对比 500 个并发,也说明 500 个并发就是系统的瓶颈。Page ( 14 ) of ( 19 )5.6 1000 个并发测试情况从 20 个并发,每 10 秒钟增加 20 个并发,逐渐增大到 1000 个并发。从下面图表可以看出响应时间(图 1)逐渐的增大,当增大到 800 个并发后,系统的响应时间基本上都超过了 10s,系统此时超时率非常大。在 600 个并发左右时系统的流量吞吐量、TPS 并没有继续增大,开始保持平稳的曲线。跟 500 个并发对比,可以说明 50060

11、0 之间就是系统的瓶颈。再增大并发,系统已经不能处理。系统队列增大,失败率增多。随着并发的增大,系统在 1000 个并发下压测 5 分钟,系统并没有奔溃。停止压测后,重新访问系统,系统还能正常响应,说明系统是可恢复性的。Page ( 15 ) of ( 19 )5.7 错误分析问题 1: Non HTTP response code: .SocketTimeoutException/Non HTTP response message: Read timed out系统处理不了那么多情况,压测请求连接不上服务。Page ( 16 ) of ( 19 )问题 2: Non HTTP respons

12、e code: .SocketTimeoutException/Non HTTP response message: connect timed out系统处理不了那么多情况,压测请求连接不上服务。问题 3: Non HTTP response code: org.apache.http.NoHttpResponseException/Non HTTP response message: :443 failed to respond系统处理不了那么多情况,系统超时。问题 4: Non HTTP response code: .SocketException/Non HTTP response

13、message: Connection reset系统处理不了那么多情况,压测请求连接不上服务。Page ( 17 ) of ( 19 )6.测试结论500600 之间就是系统的瓶颈。再增大并发,系统已经不能处理。系统队列增大,失败率增多。随着并发的增大,当并发达到 1000 个时,80%的请求超时。在 1000 并发下压测 5 分钟,系统还在正常运行,系统能承受 1000 个并发的冲击。建议:(1) 优化 tomcat 线程、内存的配置。(2) 为数据库增加索引和缓存。(3) 增加分布式部署。(4) 再继续几轮压测。Page ( 18 ) of ( 19 )7.风险分析由于系统服务器没有做全

14、面的监控,包括服务器、数据。不能确定是哪个组件的瓶颈。Page ( 19 ) of ( 19 )8. 附录图表指标说明序 号 指 标 说 明1 Response Times Over Time 按 时 间 的 变 化 呈 现 系 统 响 应 时 间 的 变 化 曲 线2 Active Threads Over Time 按 时 间 的 变 化 呈 现 并 发 请 求 数 的 变 化 曲 线3 Bytes Throughput Over Time按 时 间 的 变 化 呈 现 压 测 过 程 中 发 送 和 接 收 到 的 流 量变 化 曲 线4 Transactions Per Second 按 时 间 的 变 化 呈 现 每 秒 钟 通 过 的 事 务 数 曲 线5 Hits Per Second 按 时 间 的 变 化 呈 现 每 秒 钟 压 测 发 出 去 的 请 求 数 曲 线6 Time Vs Threads 呈 现 响 应 时 间 与 并 发 请 求 的 关 系 曲 线

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 实用文档 > 工作总结

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报