压测和性能分析方法论
2023-02-22 09:10:16来源：后端系统和架构
压测类型一般分为单服务压测和全链路压测两种压测类型。
(相关资料图)
而我们常见的施压模式有以下两种:
并发模式（以用户角度来模拟用户模式）并发是指并发用户数，从业务角度来模拟同时在线的用户数，从而达到预期的并发量，要计算吞吐的话还需要做个转换。但是在某些场景比较符合场景的预期
RPS 模式（以请求的吞吐量角度来模拟吞吐模式）
RPS（Requests Per Second）是指每秒请求数。RPS 模式即“吞吐量模式”，通过设置每秒发出的请求数，从服务端的角度出发，直接衡量系统的吞吐能力，免去并发到 RPS 的繁琐转化，一步到位。并发模式与 RPS 模式没有优劣，各自有各自适用的场景。
常用压测工具常用压测工具如下：
wrk: https://github.com/wg/wrkab: https://httpd.apache.org/docs/2.4/programs/ab.htmlwebbench性能指标常见性能指标业务指标：并发数、吞吐量、响应时间并发数。是指系统同时处理的请求数，对于互联网系统而言，一般就是指同时访问系统的用户数。吞吐量(QPS 的最大值)：是指单位时间内系统处理请求的数量，体现的是系统的处理能力。我们一般用 TPS、 QPS 这样的指标来衡量。吞吐量还有平均吞吐量、峰值吞吐量、最低吞吐量之分。响应时间：一次事务的处理时间。通常指从一个请求发出，到服务器进行处理后返回，再到接收完毕应答数据的时间间隔。一般有平均响应时间、P95、P99 之分。响应时间和吞吐量要达到一个平衡点，随着吞吐量的增加，响应时间会先维持一个点，然后会开始迅速加大，随之而来的是吞吐量也很难上去了。我们对响应时间是有要求的，因此我们不能只追求吞吐量，一定是在一个合理的响应时间内找到最大的吞吐量。
响应时间一定是在成功率的基础上的， 如果出现失败，那么这个响应时间是无效的。成功率一般要 100%。
他们之间的关系是：
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% 递减的方式来粗略评估。最后需要注意，集群的整体抗量能力需要根据实际情况去达到一个合理的配置，并不是集群中的机器越多越好。压到一个符合预期的值即可。文转载自微信公众号「 后端系统和架构」，作者「AllenWu」，可以通过以下二维码关注。
转载本文请联系「后端系统和架构」公众号。
