性能测试报告

接口性能测试报告Rev：A.1编制软件测试工程师***日期批准架构师***日期Page(Page(#)of(17)目录TOC\o"1-5"\h\z\o"CurrentDocument"1.概述31.1目的3\o"CurrentDocument"1.2术语3\o"CurrentDocument"1.3参考资料3第1章需求分析错误!未定义书签。2.项目背景错误!未定义书签。2.1部署结构图错误!未定义书签。2.2系统架构图错误!未定义书签。TOC\o"1-5"\h\z测试资源5\o"CurrentDocument"3.1测试环境5\o"CurrentDocument"3.2人力资源53.3测试工具错误!未定义书签。(1)Jemeter工具介绍错误!未定义书签。(2)工作原理错误!未定义书签。(4)Jmeter图表指标说明错误!未定义书签。JVM监控工具错误!未定义书签。服务器资源监控工具错误!未定义书签。测试策略6测试目标错误!未定义书签。测试方法错误!未定义书签。测试内容错误!未定义书签。缺陷处理规范错误!未定义书签。测试产物错误!未定义书签。5.测试计划错误!未定义书签。6.风险分析131概述1.1该文档详细描述压力测试过程、测试监控数据以及测试数据分析结论。1.2术语负载测试：通过测试工具不断增大压力，查看系统性能表现的一个测试过程。负载机：发送请求，生产测试压力的机器。1.3参考资料《》测试需求2.1被测系统分析**是一个试点项目，**正在接入到**项目中来，通过**系统可以直接进入到**平台。后续用户量会随着**系统用户的接入逐渐增大。11月**系统会展示到互联网大会上0，预计互联网大会访问量会到达一万以上，这么大的用户访问量必然对我们的系统造成很大的考验。当前**部署在一台2核4G的阿里云服务器上，在这样低的性能机器上系统能处理很大

的并发是不可能的。目前系统注册和使用用户非常少，并不会对系统造成威胁。但是系统的

处理效率、容量和稳定性未经过验证，还不确定系统在单服务器的效率、容量和稳定性。测试通过标准通过指标错误率<5%响应时间<5sCPU<75%内存<75%测试前置操作3.1测试环境首先测试服务器有限，没有独立的服务器供压测使用。其次**线上用户量非常少，压测非订单业务接口不影响生产环境的运行，所以选择合适的时间在生产环境下直接压测。系统的api接口、dubbo月服务和mysql服务器都在同一台月服务器，配置都是默认的，没有经过优化。性能测试环境jdk版本jdk1.8部署容器apache-tomcat-8测试工具Jmeter3.2Jmeter负载服务器4核8GCentOS64位4台mysql数据库月服务器4核8GCentOS64位1台Web应用月服务器与数据库月服务器共用测试脚本如下附件：基础数据没有历史数据可以参考，不需要构造基础数据，直接使用生产环境已有的数据。3.4人力资源测试1人、后台服务开发1人。

序号角色人数职责1性能测试工程师1性能测试方案性能测试脚本性能执行测试和分析性能测试报告2后台月服务开发工程师1协查性能测试过程问题协助分析性能测试结果3.5负载场景配置配置项设置CC十C厂十Tr3000(3s)Ilillikiii1ie设乂i断言ConstantTiiiieiResponseAssertion3000(3s)断言集合点设置L-z1i\1L1L-z11SynchronizingTimerNumberofSimulatedtoGroup1L>/\L1\L-z1~x-idkJx-JL1II1y并发数by3000(3s)H盯P请求默认值Cc小4-ii+3000(3s)10000(10s)ConnecttiiiieOutDz->r'r>z-\r^r'r>厂、ii十丄0000(10s)10000(10八ResponsetimieOutCd>十f十Mic丄0000(10s)i>tf8Lisenercontentencoding无支架使用-l生成csv文件，保存timeStamp,elapsed,label,responseCode,responseMessage,threadName,success,failureMessage,bytes,sentBytes,grpThreads,allThrea3.6测试监控应用服务器监控：使用linux自带的top、vmstat命令监控服务器资源Tomcat的JVM监控:使用jdk自带的jmap、jstat查看内存、线程、类的情况。数据库监控：没有做监控。后续可以增加慢查询的跟踪。负载机监控：使用linux自带的top、vmstat命令监控服务器资源备注：由于是生产环境，所以没有使用第三方工具进行监控。

测试场景设计4.1测试场景压测场景序号测试场景并发数备注2用100个并发压测综合业务，每个业务分配25个并发.循环压测20次100验证脚本的正确性3用200个并发压测综合业务，每个业务分配50个并发，循环压测20次200翻倍增大并发，检验系统的性能6用500个并发压测综合业务，每个业务分配125个并发，循环压测20次500增大到500并发，检验系统的性能由于超时率高与预期，需要降低并发压测，压测过程中增加这二个场景。4用300个并发压测综合业务，每个业务分配75个并发，循环压测20次300减小并发，检验系统的性能超时率是否有减少5用400个并发压测综合业务，每个业务分配100个并发.循环压测20次400增大并发，检验系统的性能7从20个并发开始测试，每隔10s钟增加20个并发，逐渐增大到1000个并发，并持续压测5分钟。1000从0逐渐增大到1000，检验系统随着并发的增大系统的处理效率是一个什么样的反应。4.2相关业务接口测试用例从**入口进入**首页、商家详情页、商品详情页、商品列表、商家列表四个业务同时压测，每个业务相关的接口按列表中的顺序逐一请求。测试过程整个测试过程中5.1100个并发测试情况整个测试过程不管是错误率还是响应时间都是正常,系统响应很快，基本上小于400ms。6004002000D9;00WD9;05W0^10:00山匚tiveThreadsOverTimeC?：00：OW9：05：ODD9：10:00TransactionsPer5亡匚and0^:00:00DD:05:ODC9:10:MHitsPerSecond-CO50□09:CiO:000?:05:00D?:10:005.2200个并发测试情况翻倍增加了并发数后，系统的响应有较大幅度的变厉害，部分接口响应时间翻倍，但是整个过程中平均响应时间小于2s，TPS（如图4）有所增长，达到预定指标。ResponseTimesOverTime10:32:0010：3+W10:36*0ActiveThreadsOverTmeResponseTimesOverTime10:32:0010：3+W10:36*0ActiveThreadsOverTme5.3500个并发测试情况继续增大并发量，翻倍增加了并发数后，系统整体的性能变化很大TPS和流量吞吐量都没有什么增长系统的响应时间从原来小于2s到现在2s〜10s之间超时率达到了4.43%。说明系统处理效率已经达到了瓶颈。继续减小并发查看系统的表现。5000011:20:0011:25:00托。■冉uti常亡Th「亡ad吕匚Tim亡^1:20:00：2E：5000011:20:0011:25:00托。■冉uti常亡Th「亡ad吕匚Tim亡^1:20:00：2E：C0fl500000250000BytesThroughputOverTme11;20;0011;25;0QTransaiztionsPerSecondPHitsPerSecond11:20:0011：25：005.4300个并发测试情况减少到300个并发后,系统的响应时间、tps、流量吞吐量都跟200个并发差不多。继续增大并发查看系统性能表现。ResponseTmesO^erTimeActiveThreadsOverTime500000250000BytesThroLFghputOverTinne-1：-3D：C-0-1ResponseTmesO^erTimeActiveThreadsOverTime500000250000BytesThroLFghputOverTinne-1：-3D：C-0-1：05：GO「mClJ1:0£-:005.5400个并发测试情况增大到400个并发后，系统响应时间有所增大，比300个并发慢2〜3s。TPS比300个稍大，流量吞吐量没什么大的变化。系统还是处理比较正常的。对比500个并发，也说明500个并发就是系统的瓶颈。ResponseTimesOverTimeActiv亡ThreadsOverTimeBytESThroughputCv亡「TimETranmmttiorimPerSecond53■^1:15:00J1：1C'：C'OHitsPerSecondResponseTimesOverTimeActiv亡ThreadsOverTimeBytESThroughputCv亡「TimETranmmttiorimPerSecond53■^1:15:00J1：1C'：C'OHitsPerSecondimeVsThreads5.61000个并发测试情况从20个并发，每10秒钟增加20个并发，逐渐增大到1000个并发。从下面图表可以看出响应时间（图1）逐渐的增大，当增大到800个并发后，系统的响应时间基本上都超过了10s，系统此时超时率非常大。在600个并发左右时系统的流量吞吐量、TPS并没有继续增大，开始保持平稳的曲线。跟500个并发对比，可以说明500~600之间就是系统的瓶颈。再增大并发，系统已经不能处理。系统队列增大，失败率增多。随着并发的增大，系统在1000个并发下压测5分钟，系统并没有奔溃。停止压测后，重新访问系统，系统还能正常响应，说明系统是可恢复性的。5-30DOOActiveThreadsOverTimeTrarsactiansPerSecond□fIBytesThroughputOverTime250000DM：5C'5-30DOOActiveThreadsOverTimeTrarsactiansPerSecond□fIBytesThroughputOverTime250000DM：5C'：ij0-2：00：DD0^―T：5ij：C'O12：00WHitsPerSecond

000-1：5ijHitsPerSecond

000-1：5ij：G0^2:00:00RequestsSummary■KO■okQK7^15%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系统处理不了那么多情况，压测请求连接不上服务测试结论500~600之间就是系统的瓶颈。再增大并发，系统已经不能处理。系统队列增大，失败率增多。随着并发的增大，当并发达到1000个时，80%的请求超时。在1000并发下压测5分钟，系统还在正常运行，系统能承受1000个并发的冲击。建议：（1）优化tomcat线程、内存的配置。（2）为数据库增加索引和缓存。（3）增加分布式部署。（4）再继续几轮压测。风险分析由于系统服务器没有做全面