压测和性能分析方法论
性能测试基础
性能测试的常见分类
- • 性能测试。用来验证系统的性能是否满足设计的预期，一般来说对系统的压力会比较小，不会压垮系统，只是进行简单的验证
- • 负载测试。通过不断施加负载压力，寻找系统最优的处理能力，最好的性能状态，达到最大的性能指标。通常说来，负载测试的结果比性能测试的结果高一点。
- • 稳定性测试。可以认为是负载测试的一个子集，长时间不均匀的施压，然后看系统的各项指标是否都正常。
- • 压力测试：是我们常见的，一般我们将压测都是指这个，用来确定系统能够抗住的最大容量是多少，压力测试一般都会压到系统最大能够承受的点，然后得出一个峰值结论。
压测类型和施压模式
压测类型一般分为单服务压测和全链路压测两种压测类型。
而我们常见的施压模式有以下两种:
- • 并发模式（以用户角度来模拟用户模式）
- • 并发是指并发用户数，从业务角度来模拟同时在线的用户数，从而达到预期的并发量，要计算吞吐的话还需要做个转换。但是在某些场景比较符合场景的预期
- • RPS 模式（以请求的吞吐量角度来模拟吞吐模式）
- • RPS（Requests Per Second）是指每秒请求数。RPS 模式即“吞吐量模式”，通过设置每秒发出的请求数，从服务端的角度出发，直接衡量系统的吞吐能力，免去并发到 RPS 的繁琐转化，一步到位。
并发模式与 RPS 模式没有优劣，各自有各自适用的场景。
常用压测工具
常用压测工具如下：
- • wrk: https://github.com/wg/wrk
- • ab: https://httpd.apache.org/docs/2.4/programs/ab.html
- • webbench
性能指标
常见性能指标
业务指标：并发数、吞吐量、响应时间
- • 并发数。是指系统同时处理的请求数，对于互联网系统而言，一般就是指同时访问系统的用户数。
- • 吞吐量(QPS 的最大值)：是指单位时间内系统处理请求的数量，体现的是系统的处理能力。我们一般用 TPS、 QPS 这样的指标来衡量。吞吐量还有平均吞吐量、峰值吞吐量、最低吞吐量之分。
- • 响应时间：一次事务的处理时间。通常指从一个请求发出，到服务器进行处理后返回，再到接收完毕应答数据的时间间隔。一般有平均响应时间、P95、P99 之分。
- • 响应时间和吞吐量要达到一个平衡点，随着吞吐量的增加，响应时间会先维持一个点，然后会开始迅速加大，随之而来的是吞吐量也很难上去了。我们对响应时间是有要求的，因此我们不能只追求吞吐量，一定是在一个合理的响应时间内找到最大的吞吐量。
- • 响应时间一定是在成功率的基础上的， 如果出现失败，那么这个响应时间是无效的。成功率一般要 100%。
他们之间的关系是：
代码语言：javascript复制QPS（TPS）= 并发数 / 平均响应时间
吞吐量理论值 = 并发数 / 平均响应时间
并发数 = QPS*平均响应时间系统资源：CPU空闲率、内存使用、网络IO、磁盘读写量、句柄数等
性能计数器，指的是服务器或者操作系统性能的一些指标数据，包括系统负载 System Load、对象和线程数、内存使用、CPU 使用、磁盘和网络 I/O 使用等指标。这些指标是系统监控的重要参数，反映系统负载和处理能力的一些关键指标，通常这些指标和性能是强相关的。这些指标很高，成为瓶颈，通常也预示着性能可能会出现问题。
最优的方式是采用百分比
参考 平均值是不靠谱的，最为正确的统计做法是用百分比分布统计 一文，最佳实践经验是采用百分比。比如 Top Percentile（TP）指标 ，TP50的意思是指 50%的请求都小于某个值，TP90表示90%的请求小于某个时间。
压测观察指标
不管是哪种压测类型，压测要观察的指标一般需要包括：
- • 成功率、失败率
- • 系统资源（CPU、内存、带宽、IO）
- • 响应时间，平均响应时间、P95/P99响应时间，一定要关注 P95 和 P99，不能只看平均时间，P99 时间可以较好的去判别线上用户的时间体验
- • 吞吐量(QPS/TPS)
一个基本的压测数据示例如下：
生成严谨的压测报告
我们分析系统性能问题，需要找准要点，这就要求我们的压测报告要确实有效，是要非常严谨的，条理清晰， 要一步一步分析出瓶颈，而且要明白为啥到了瓶颈，然后怎么优化？因此就要求我们要输出严谨的压测报告。这里有一些经验：
- • 压测的时候，要找到一个性能拐点；如果压力一上来就达到瓶颈了，那么还需要往回调一点，直到找到一个最佳的性能拐点。系统性能是一个抛物线形态，到达性能峰值后继续施压会导致性能下降，因此我们压测最重要的就是找到那个最佳的性能拐点。因此整个施压过程逐步施压，到达性能峰值后继续施压，如果继续施压后性能不升反降就说明到了拐点了
- • 如何分析性能瓶颈，找到 QPS 提升不上去的原因呢?
- • QPS 不会一直上升，到某个点后就会持平甚至下降，出现性能拐点，此时就需要开始分析原因。
- • 具体的方式就是，先抓没有到极限的 profile 情况(cpu,block,io,内存)，再抓刚好到极限的，最后抓已经超过极限的，然后分析这几种情况下，到底是哪个系统资源，或者外部接口导致了性能问题。
- • 如果是某个组件或者外部服务是性能瓶颈点，那么还需要进一步分析下，是不是组件的使用姿势不对？是不是没处理好连接数？不能说一找到某个组件的问题就结束了，还需要进一步更深层的审视下。
- • 分别知道单机和集群能够承载的性能和拐点
- • 单台机器的最大 QPS 是多少？
- • 平行扩展后的 QPS 又是多少，是线性增长么?（肯定不会线性增长, 到某个程度后相关资源一定都会出现瓶颈，关键是要找到对应的瓶颈点）
- • 系统资源如何分析，举个 CPU 的例子
- • 首先看 CPU，如果 CPU 没有跑满，则说明不是 CPU 的问题，就不用关心CPU，然后就要其他的资源如 io, swap, 内存, 网卡等
- • 如果有多个 CPU 核心, 则观察每个核心的 cpu 的使用情况，不能光看整体的 CPU 使用率
- • 如果 CPU 跑满了，那么抓 CPU 的 profile, 观测看看哪个调用比较耗时.
做好容量预估
系统上线前就必须要能够有预估/评估大概, 再通过压测验证, 了解每个细节,包括资源, 依赖关系, 部署情况, 机房分布, 降级策略, 容灾方案, 备用方案
容量预估是大型系统上线的必备品，因为只有合理的进行容量预估，才能更好的去根据系统要承载的量级去设计我们的系统，容量规划需要尽量做到以最少的机器抗住更多的流量；规划 ok 了之后，我们需要用一些性能压测手段来验证是否符合预期。有了合理的容量规划和评估之后，上线之前去压测系统的时候才能知道我们需要压到什么程度，然后，容量预估并不是拍脑袋的，容量评估需要考虑如下几点：
- 1. 得到业务指标，评估总访问量
- • 询问产品、运营得到一些 uv、pv等指标
- 2. 评估平均访问量 QPS
- • 一天86400秒，一般认为请求发生在白天，即4w秒。
- • 总量除以总时间，一天算4w秒；
- 3. 评估高峰 QPS
- • 系统容量规划时，不能只考虑平均 QPS，而是要抗住高峰的 QPS
- • 根据业务曲线图来
- • 一般高峰 QPS 是平均 QPS 的 3-4 倍
- 4. 评估整个业务体系下各个模块、子系统的相关指标
- 5. 评估系统、单机极限 QPS，评估需要多少机器
- • 进行压测和数据分析
- 6. 适当冗余度，对压测得到的结果，我们实际上线后要做点冗余，避免线上实际压力太大导致无法快速扩容
做好分析总结
要做好分析总结，比如：
- • 这个系统上线后，真能抗的住么 ? 除了有压测的数据，还要有自己有预估。自己的系统，哪些方面可能存在瓶颈, 会导致上线后出问题的? 系统上线前要有充分准备和整体评估/预估。
- • 系统上线后，万一扛不住怎么解决？是否有限流方案？是否有降级方案？
- • 系统现在 10w 用户是什么情况? 那么假如 1000w用户的情况, 是不是线性增长呢?需要做些什么考虑呢？
- • 系统上线前就必须要能够有预估/评估大概, 再通过压测验证, 了解每个细节,包括资源, 依赖关系, 部署情况, 机房分布, 降级策略, 容灾方案, 备用方案
一些具体 case 的压测方法
测试数据准备
高质量的测试数据应当能真实的反映用户的使用场景，我们一般会选择以线上真实数据作为数据源，经过采样、过滤、脱敏，作为性能测试的测试数据。但是在拿真实数据测试之前，必须要先线下模拟测试数据，至少先验证整个系统的基本性能需求后才能拿真实数据做性能测试。
存储层（数据库和缓存）的压测方法
针对无状态服务的话，要提高并发能力很容易，可以无脑扩容。但是针对有状态的存储系统，它能支持的最大并发数不是可以无限扩展的，因此我们一定要能够清楚我们的数据存储层能抗多少量，而针对这种存储集群的压测，一般就是：
- • 首先针对单机进行压测
- • 然后再去分析，集群的整体抗量能力，需要注意，集群能够承载的量不是单机的累加值，一般在集群中每增加一台机器，可以采用 80% 递减的方式来粗略评估。
- • 最后需要注意，集群的整体抗量能力需要根据实际情况去达到一个合理的配置，并不是集群中的机器越多越好。压到一个符合预期的值即可。
