性能测试报告.docx
《性能测试报告.docx》由会员分享,可在线阅读,更多相关《性能测试报告.docx(13页珍藏版)》请在冰豆网上搜索。
性能测试报告
接口性能测试报告
Rev:
A.1
编制
软件测试工程师
***
日期
批准
架构师
***
日期
1概述
1.1目的
该文档详细描述压力测试过程、测试监控数据以及测试数据分析结论。
1.2术语
负载测试:
通过测试工具不断增大压力,查看系统性能表现的一个测试过程。
负载机:
发送请求,生产测试压力的机器。
1.3参考资料
《》
2.测试需求
2.1被测系统分析
**是一个试点项目,**正在接入到**项目中来,通过**系统可以直接进入到**平台。
后续用户量会随着**系统用户的接入逐渐增大。
11月**系统会展示到互联网大会上0,预计互联网大会访问量会到达一万以上,这么大的用户访问量必然对我们的系统造成很大的考验。
当前**部署在一台2核4G的阿里云服务器上,在这样低的性能机器上系统能处理很大的并发是不可能的。
目前系统注册和使用用户非常少,并不会对系统造成威胁。
但是系统的处理效率、容量和稳定性未经过验证,还不确定系统在单服务器的效率、容量和稳定性。
2.2测试通过标准
通过指标
错误率
<5%
响应时间
<5s
CPU
<75%
内存
<75%
3.测试前置操作
第1章
3.1测试环境
首先测试服务器有限,没有独立的服务器供压测使用。
其次**线上用户量非常少,压测非订单业务接口不影响生产环境的运行,所以选择合适的时间在生产环境下直接压测。
系统的api接口、dubbo服务和mysql服务器都在同一台服务器,配置都是默认的,没有经过优化。
性能测试环境
jdk版本
jdk1.8
部署容器
apache-tomcat-8
测试工具
Jmeter3.2
Jmeter负载服务器
4核8GCentOS64位4台
mysql数据库服务器
4核8GCentOS64位1台
Web应用服务器
与数据库服务器共用
3.2测试脚本
如下附件:
3.3基础数据
没有历史数据可以参考,不需要构造基础数据,直接使用生产环境已有的数据。
3.4人力资源
测试1人、后台服务开发1人。
序号
角色
人数
职责
1
性能测试工程师
1
性能测试方案
性能测试脚本
性能执行测试和分析
性能测试报告
2
后台服务开发工程师
1
协查性能测试过程问题
协助分析性能测试结果
3.5负载场景配置
3.6测试监控
(1)应用服务器监控:
使用linux自带的top、vmstat命令监控服务器资源
(2)Tomcat的JVM监控:
使用jdk自带的jmap、jstat查看内存、线程、类的情况。
(3)数据库监控:
没有做监控。
后续可以增加慢查询的跟踪。
(4)负载机监控:
使用linux自带的top、vmstat命令监控服务器资源
备注:
由于是生产环境,所以没有使用第三方工具进行监控。
4.测试场景设计
4.1测试场景
4.2相关业务接口
4.3测试用例
从**入口进入**首页、商家详情页、商品详情页、商品列表、商家列表四个业务同时压测,每个业务相关的接口按列表中的顺序逐一请求。
5.测试过程
整个测试过程中
5.1100个并发测试情况
整个测试过程不管是错误率还是响应时间都是正常,系统响应很快,基本上小于400ms。
5.2200个并发测试情况
翻倍增加了并发数后,系统的响应有较大幅度的变厉害,部分接口响应时间翻倍,但是整个过程中平均响应时间小于2s,TPS(如图4)有所增长,达到预定指标。
5.3500个并发测试情况
继续增大并发量,翻倍增加了并发数后,系统整体的性能变化很大TPS和流量吞吐量都没有什么增长,系统的响应时间从原来小于2s到现在2s~10s之间,超时率达到了4.43%。
说明系统处理效率已经达到了瓶颈。
继续减小并发查看系统的表现。
5.4300个并发测试情况
减少到300个并发后,系统的响应时间、tps、流量吞吐量都跟200个并发差不多。
继续增大并发查看系统性能表现。
5.5400个并发测试情况
增大到400个并发后,系统响应时间有所增大,比300个并发慢2~3s。
TPS比300个稍大,流量吞吐量没什么大的变化。
系统还是处理比较正常的。
对比500个并发,也说明500个并发就是系统的瓶颈。
5.61000个并发测试情况
从20个并发,每10秒钟增加20个并发,逐渐增大到1000个并发。
从下面图表可以看出响应时间(图1)逐渐的增大,当增大到800个并发后,系统的响应时间基本上都超过了10s,系统此时超时率非常大。
在600个并发左右时系统的流量吞吐量、TPS并没有继续增大,开始保持平稳的曲线。
跟500个并发对比,可以说明500~600之间就是系统的瓶颈。
再增大并发,系统已经不能处理。
系统队列增大,失败率增多。
随着并发的增大,系统在1000个并发下压测5分钟,系统并没有奔溃。
停止压测后,重新访问系统,系统还能正常响应,说明系统是可恢复性的。
5.7错误分析
问题1:
NonHTTPresponsecode:
.SocketTimeoutException/NonHTTPresponsemessage:
Readtimedout
系统处理不了那么多情况,压测请求连接不上服务。
问题2:
NonHTTPresponsecode:
.SocketTimeoutException/NonHTTPresponsemessage:
connecttimedout
系统处理不了那么多情况,压测请求连接不上服务。
问题3:
NonHTTPresponsecode:
org.apache.http.NoHttpResponseException/NonHTTPresponsemessage:
:
443failedtorespond
系统处理不了那么多情况,系统超时。
问题4:
NonHTTPresponsecode:
.SocketException/NonHTTPresponsemessage:
Connectionreset
系统处理不了那么多情况,压测请求连接不上服务。
6.测试结论
500~600之间就是系统的瓶颈。
再增大并发,系统已经不能处理。
系统队列增大,失败率增多。
随着并发的增大,当并发达到1000个时,80%的请求超时。
在1000并发下压测5分钟,系统还在正常运行,系统能承受1000个并发的冲击。
建议:
(1)优化tomcat线程、内存的配置。
(2)为数据库增加索引和缓存。
(3)增加分布式部署。
(4)再继续几轮压测。
7.风险分析
由于系统服务器没有做全面的监控,包括服务器、数据。
不能确定是哪个组件的瓶颈。
8.附录
图表指标说明