压测和性能分析方法论简述

lsekfe

压测和性能分析方法论
　　性能测试基础
　　性能测试的常见分类
　　性能测试。用来验证系统的性能是否满足设计的预期，一般来说对系统的压力会比较小，不会压垮系统，只是进行简单的验证。
　　负载测试。通过不断施加负载压力，寻找系统最优的处理能力，最好的性能状态，达到最大的性能指标。通常说来，负载测试的结果比性能测试的结果高一点。
　　稳定性测试。可以认为是负载测试的一个子集，长时间不均匀的施压，然后看系统的各项指标是否都正常。
　　压力测试：是我们常见的，一般我们将压测都是指这个，用来确定系统能够抗住的最大容量是多少，压力测试一般都会压到系统最大能够承受的点，然后得出一个峰值结论。
　　压测类型和施压模式
　　压测类型一般分为单服务压测和全链路压测两种压测类型。
　　而我们常见的施压模式有以下两种:
　　·并发模式（以用户角度来模拟用户模式）
　　并发是指并发用户数，从业务角度来模拟同时在线的用户数，从而达到预期的并发量，要计算吞吐的话还需要做个转换。但是在某些场景比较符合场景的预期
　　· 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%。
　　他们之间的关系是：
　　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% 递减的方式来粗略评估。
　　· 最后需要注意，集群的整体抗量能力需要根据实际情况去达到一个合理的配置，并不是集群中的机器越多越好。压到一个符合预期的值即可。

oliver.tang

学习了