测试工作总结–性能测试相关问题

1. HTTP通信原理

1. 浏览器基于url域名解析出url地址
2. 基于IP地址和服务器进行连接
3. 客户端构造HTTP请求，包含头部信息和通信数据
4. 基于HTTP 络协议传递请求至服务端对应接口
5. 接口生成响应结构
6. 响应结果基于HTTP原路返回
7. 基于前端渲染,将生成结果进行展示

2. 性能测试需求

给开发，运维团队提供

1. 容量规划能力
2. 系统风险识别
3. 系统瓶颈识别
4. 性能调优指导

3. 性能测试与分析优化（技术树）

1. 代码调优
2. 操作系统os
3. 数据库
4. 存储
5. 应用服务器、中间件
6. 络
7. 压测
8. 监控分析工具
9. 缓存
10. 队列
11. web服务器
12. 容器化、编排、 络
13. 大数据技术

4. 系统性能问题

1. 存储问题 Mysql、redis、Memcache
2. 中间件问题 Tomcat、httpd
3. 消息队列问题 kafka、ActiveMQ
4. 调用链路问题 内部依赖、第三方依赖
5. 问题详情
   1. Redis内存连接数打满
   2. Nginx拒绝连接
   3. 核心依赖服务异常
   4. 非核心依赖服务异常
   5. 软/硬件降级方案失败
   6. 消息队列积压

99. 问题案例

1. 某次压测，CPU直接打满

1. 解决步骤
   1. top 检查是那个pid占用CPU较高
   2. top -H -p pid 查看这个pid信息
   3. Pstack pid 查看堆栈信息
   4. Trace -p pid 查看对应的堆栈信息代码，具体分析哪些代码占用CPU
2. 定位问题
   1. 代码逻辑问题
   同步解析接口，使用正则的方式匹配返回内容，由于返回内容过大，导致CPU飙升

2. 某次压测，系统CPU等指标正常，偶发间段时间请求特别高

1. 日志数据：
   [Full GC(Ergonomics)[PS Young Gen: 944K -> 890K(2048K)][ParOldGen: 7129K->7129K(7168K)] 8074K->8019K(9216K), [Metaspace: 3357K->3357K(1056768K)] 0.1213761secs][Times: user = 2sces, sys = 0.00, real = 2secs]
2. 定位问题:
   1. JVM GC问题: Full GC Stop the world
3. 解决方法
   1. 减少FullGC 时间, 老年代降低

3. 某次压测, CPU/内存/ 络良好, 但响应耗时非常久, 监控查看磁盘IO异常, 追查发现日志级别为Debug

1. 定位问题:
   大量的日志打印拖累性能
2. 解决方法:
   将日志开设为Info级别

4. 某次压测, CPU/内存/ 络/磁盘指标良好, 但响应耗时久, 查看Nginx日志,发现request_time(完整交互时间)比较长, 但upstream_response_time(Nginx向后端建立请求)实际时间较短

1. 可能的问题:
   1. 发压机器的负载较高, 无法处理与后端的连接;
   2. 发压机器的 络环境与被压机器的 络环境差异较大;
2. 解决办法:
   1. 关闭其他不需要的服务, 降低发压机器负载;
   2. 将发压机器的 络环境与被压机器保持一致;

5. 某次压测, 同样并发路数, 前期性能良好, 后期数据库CPU飙升

1. 可能的问题:
   1. 产生大量级数据, 数据增长会带来性能损耗;
   2. 压测数据不合理,导致同一设备关联多个用户, 服务不做限制的in查询;
   3. 不合理的分页, 未做页数limit, 导致数据库新增数据全查询;

6. 某次稳定性, 大并发量, 前期性能良好, 分片缓存在模拟缓存单点失效后大量数据库穿透

1. 可能的问题
   1. 缓存不合理的分片策略, 使用除模的方式,导致大量缓存同一时间失效
   2. 不合理的负载均衡算法
2. 解决方法:
   1. 一致性Hash解决缓存问题

7. 某次稳定性, 如果HTTP入口流量只有百QPS,但下游RPC打挂

1. 问题定位
   医疗列表数据, for循环调用下游解决, 导致请求数百倍扩大
2. 解决方案:
   使用batch接口减轻压力(可能会带来功能隐患)