接口性能测试报告Rev：A.1目录1.概述 (4)1.1 目的 (4)1.2 术语 (4)1.3 参考资料 (4)第1章需求分析.................................................................................. 错误!未定义书签。
2.项目背景................................................................................. 错误!未定义书签。
2.1 部署结构图............................................................................................ 错误!未定义书签。
2.2 系统架构图............................................................................................ 错误!未定义书签。
3.测试资源 (6)3.1 测试环境 (6)3.2 人力资源 (6)3.3 测试工具................................................................................................ 错误!未定义书签。
（1）Jemeter工具介绍.................................................................... 错误!未定义书签。
（2）工作原理..................................................................................... 错误!未定义书签。
（4）Jmeter图表指标说明.............................................................. 错误!未定义书签。
（3）JVM监控工具........................................................................... 错误!未定义书签。
（4）服务器资源监控工具................................................................ 错误!未定义书签。
4.测试策略 (7)4.1 测试目标 ........................................................................................... 错误!未定义书签。
4.2 测试方法 ........................................................................................... 错误!未定义书签。
4.3 测试内容 ........................................................................................... 错误!未定义书签。
4.4 缺陷处理规范................................................................................... 错误!未定义书签。
4.5 测试产物 ........................................................................................... 错误!未定义书签。
5.测试计划................................................................................. 错误!未定义书签。
6.风险分析 (15)1 概述1.1 目的该文档详细描述压力测试过程、测试监控数据以及测试数据分析结论。
1.2 术语负载测试：通过测试工具不断增大压力，查看系统性能表现的一个测试过程。
负载机：发送请求，生产测试压力的机器。
1.3 参考资料《》2.测试需求2.1被测系统分析**是一个试点项目，**正在接入到**项目中来，通过**系统可以直接进入到**平台。
后续用户量会随着**系统用户的接入逐渐增大。
11月**系统会展示到互联网大会上0，预计互联网大会访问量会到达一万以上，这么大的用户访问量必然对我们的系统造成很大的考验。
当前**部署在一台2核4G的阿里云服务器上，在这样低的性能机器上系统能处理很大的并发是不可能的。
目前系统注册和使用用户非常少，并不会对系统造成威胁。
但是系统的处理效率、容量和稳定性未经过验证，还不确定系统在单服务器的效率、容量和稳定性。
2.2 测试通过标准3.测试前置操作3.1 测试环境首先测试服务器有限，没有独立的服务器供压测使用。
其次**线上用户量非常少，压测非订单业务接口不影响生产环境的运行，所以选择合适的时间在生产环境下直接压测。
系统的api接口、dubbo服务和mysql服务器都在同一台服务器，配置都是默认的，没有经过优化。
3.2 测试脚本如下附件：3.3 基础数据没有历史数据可以参考，不需要构造基础数据，直接使用生产环境已有的数据。
3.4 人力资源测试1人、后台服务开发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.1 100个并发测试情况整个测试过程不管是错误率还是响应时间都是正常，系统响应很快，基本上小于400ms。
5.2 200个并发测试情况翻倍增加了并发数后，系统的响应有较大幅度的变厉害，部分接口响应时间翻倍，但是整个过程中平均响应时间小于2s，TPS（如图4）有所增长，达到预定指标。
5.3 500个并发测试情况继续增大并发量，翻倍增加了并发数后，系统整体的性能变化很大TPS和流量吞吐量都没有什么增长，系统的响应时间从原来小于2s到现在2s~10s之间，超时率达到了4.43%。
说明系统处理效率已经达到了瓶颈。
继续减小并发查看系统的表现。
5.4 300个并发测试情况减少到300个并发后，系统的响应时间、tps、流量吞吐量都跟200个并发差不多。
继续增大并发查看系统性能表现。
5.5 400个并发测试情况增大到400个并发后，系统响应时间有所增大，比300个并发慢2~3s。
TPS比300个稍大，流量吞吐量没什么大的变化。
系统还是处理比较正常的。
对比500个并发，也说明500个并发就是系统的瓶颈。
5.6 1000个并发测试情况从20个并发，每10秒钟增加20个并发，逐渐增大到1000个并发。
从下面图表可以看出响应时间（图1）逐渐的增大，当增大到800个并发后，系统的响应时间基本上都超过了10s，系统此时超时率非常大。
在600个并发左右时系统的流量吞吐量、TPS 并没有继续增大，开始保持平稳的曲线。
跟500个并发对比，可以说明500~600之间就是系统的瓶颈。
再增大并发，系统已经不能处理。
系统队列增大，失败率增多。
随着并发的增大，系统在1000个并发下压测5分钟，系统并没有奔溃。
停止压测后，重新访问系统，系统还能正常响应，说明系统是可恢复性的。
5.7 错误分析问题1：Non HTTP response code: .SocketTimeoutException/Non HTTP response message: Read timed out系统处理不了那么多情况，压测请求连接不上服务。
问题2：Non HTTP response 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 message: Connection reset系统处理不了那么多情况，压测请求连接不上服务。
6.测试结论500~600之间就是系统的瓶颈。
再增大并发，系统已经不能处理。
系统队列增大，失败率增多。
随着并发的增大，当并发达到1000个时，80%的请求超时。
在1000并发下压测5分钟，系统还在正常运行，系统能承受1000个并发的冲击。
建议：（1）优化tomcat线程、内存的配置。
（2）为数据库增加索引和缓存。
（3）增加分布式部署。
（4）再继续几轮压测。
7.风险分析由于系统服务器没有做全面的监控，包括服务器、数据。
不能确定是哪个组件的瓶颈。
8.附录图表指标说明。