引言

性能测试 Performance Test

部分概念参考自极客时间高楼老师性能测试相关的专栏

性能这件事，并不能仅局限于「测试」这一点，而应该是一个完整的工程，需要一个有技术有话语权的人来从上到下的去主导

性能工程是指，通过分析业务逻辑和技术架构，创建性能模型，制定性能方案，准备应用环境，设计并实施性能部署监控，实现符合真实业务逻辑的压力，通过监控手段获取各组件的性能计数器，分析计数器采集出的数据，查找出性能瓶颈的根本原因并优化，最后通过环比生产环境的性能数据修正场景。

目标和意义

• 验证系统的稳定性和可靠性，识别性能瓶颈和拐点
• 提供资源和容量规划依据，降低风险，最小化成本
• 提供应用调优参考，满足用户使用需求，提升用户体验

能力阶梯图

如果测完不调，只能叫作性能验证，通常第三方性能测试机构的工作就是如此

性能工程

• 定义清晰的测试目标
  • 明确要测的功能、识别关键场景和功能模块
  • 明确性能指标和预期结果
  • 如果线上压测要注意对当前业务的影响，做好相应措施
• 选择合适的负载模型：正常负载、峰值负载、超负载
• 测试方案
  • 测试环境：尽可能与生产环境一致，最好线上压测
  • 测试工具
  • 测试数据：自己构造、日志获取
• 收集、监控
• 场景执行，观察并记录数据
  • QPS、RT、错误率（Nginx 日志和错误请求）
  • CPU 和 Memory
  • DB 和 Cache 数据写入
  • 接口功能
• 报告
  • 分析
  • 调优前后的 TPS、RT 以及资源对比图
  • 也要有安全意识，不能随便把数据分享和泄漏给别人

工具

Jemter 脚本维护困难，不支持分布式测试

Locust 系统消耗比较大，二次开发不太好

专业的性能测试团队使用 nGrinder 比较多

场景

业务场景	测试策略	目的
建立性能基线	负载、容量	寻找系统性能拐点
新上线系统验证	并发、负载、容量	系统性能摸底，告警阈值验证
寻找性能瓶颈	负载、容量、极限	不同压力下的性能表现进行对比
性能调优验证	负载、配置	验证性能优化结果，寻找平衡点
批处理能力验证	批处理、高并发	对定时任务或批量处理验证是否满足需求
高可用容灾恢复	并发、浪涌	验证系统的恢复能力和异常情况下的存活时间
系统稳定性验证	负载、稳定性	验证系统长期运行的稳定性及GC相关问题
秒杀抢购	浪涌、并发	验证高并发下系统处理能力

性能分析

通过压力工具生成 TPS、响应时间和错误率等曲线，即可判断出瓶颈是否存在（通常在最大 TPS 之前就会出现）。

再通过分段分层策略，结合监控平台、日志平台，或者其他的实时分析平台，知道架构中的哪个环节有问题，然后再根据更细化的架构图一一拆解下去。

通过曲线找到性能瓶颈

光靠平均值、最大值、最小值、中位数无法确切的分析出压测过程中服务器的具体情况，只有通过分析曲线趋势的合理性，才能判断出性能瓶颈所在的原因。

找到性能瓶颈和拐点，知己知彼，做到心中有数

• Throughput 吞吐量
• TPS 每秒事务数曲线：判断容量有多大
• RT 响应时间曲线：判断业务有多快，性能调优的重要分析对象

另外要判断瓶颈是否与压力有关，TPS 随着压力的变化而变化，那就是有关系，不管压力增不增加，TPS 都会出现曲线趋势问题，那就是无关。

构建分析决策树

分析决策树是对架构的梳理，是对系统的梳理，是对问题的梳理，是对查找证据链过程的梳理，是对分析思路的梳理。它起的是纵观全局，高屋建瓴的指导作用。

• MySQL

• 操作系统

性能调优

并发处理
现象：资源空闲，不能充分利用
调优：线程池配置、多线程并发处理、线程锁

数据库
现象：数据库CPU使用率高，慢查询多
调优：使用数据库连接池和缓存技术，优化查询语句，建立索引，分区表等

缓存优化
现象：大量重复请求（数据库、rpc接口、http接口等）
调优：使用本地缓存、Redis、es等，需避免缓存击穿和雪崩等
    出现击穿，可能是key有效期太短，没有起到缓存的作用
    如果大量数据的有效期都是一样的，同时失效，就可能会出现雪崩

MQ
功能测试，可以当成HTTP请求，看MQ后台或日志，发送/接收的消息内容是否缺少
性能测试：并发，看发送/接收情况，看时间戳，消费接收也是一样，看看到底有没有实现并发

资源管理
现象：单项资源使用率过高
调优：合理资源数据库、磁盘、网络、内存等

网络优化
现象：网络阻塞、带宽占满
调优：优化网络传输大小，减少网络使用率，使用CDN、负载均衡等技术

系统架构
现象：单点系统瓶颈
调优：使用微服务架构、分布式系统等，实现系统的水平扩展和负载均衡