压测和性能分析方法论

开发 架构
并发是指并发用户数,从业务角度来模拟同时在线的用户数,从而达到预期的并发量,要计算吞吐的话还需要做个转换。但是在某些场景比较符合场景的预期

压测和性能分析方法论

性能测试基础

性能测试的常见分类

  • 性能测试。用来验证系统的性能是否满足设计的预期,一般来说对系统的压力会比较小,不会压垮系统,只是进行简单的验证
  • 负载测试。通过不断施加负载压力,寻找系统最优的处理能力,最好的性能状态,达到最大的性能指标。通常说来,负载测试的结果比性能测试的结果高一点。
  • 稳定性测试。可以认为是负载测试的一个子集,长时间不均匀的施压,然后看系统的各项指标是否都正常。
  • 压力测试:是我们常见的,一般我们将压测都是指这个,用来确定系统能够抗住的最大容量是多少,压力测试一般都会压到系统最大能够承受的点,然后得出一个峰值结论。

压测类型和施压模式

压测类型一般分为单服务压测和全链路压测两种压测类型。

而我们常见的施压模式有以下两种:

  • 并发模式(以用户角度来模拟用户模式)

并发是指并发用户数,从业务角度来模拟同时在线的用户数,从而达到预期的并发量,要计算吞吐的话还需要做个转换。但是在某些场景比较符合场景的预期

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. 1. 得到业务指标,评估总访问量
  • 询问产品、运营得到一些 uv、pv等指标
  1. 2. 评估平均访问量 QPS
  • 一天86400秒,一般认为请求发生在白天,即4w秒。
  • 总量除以总时间,一天算4w秒;
  1. 3. 评估高峰 QPS
  • 系统容量规划时,不能只考虑平均 QPS,而是要抗住高峰的 QPS
  • 根据业务曲线图来
  • 一般高峰 QPS 是平均 QPS 的 3-4 倍
  1. 4. 评估整个业务体系下各个模块、子系统的相关指标
  2. 5. 评估系统、单机极限 QPS,评估需要多少机器
  • 进行压测和数据分析
  1. 6. 适当冗余度,对压测得到的结果,我们实际上线后要做点冗余,避免线上实际压力太大导致无法快速扩容

做好分析总结

要做好分析总结,比如:

  • 这个系统上线后,真能抗的住么 ? 除了有压测的数据,还要有自己有预估。自己的系统,哪些方面可能存在瓶颈, 会导致上线后出问题的? 系统上线前要有充分准备和整体评估/预估。
  • 系统上线后,万一扛不住怎么解决?是否有限流方案?是否有降级方案?
  • 系统现在 10w 用户是什么情况? 那么假如 1000w用户的情况, 是不是线性增长呢?需要做些什么考虑呢?
  • 系统上线前就必须要能够有预估/评估大概, 再通过压测验证, 了解每个细节,包括资源, 依赖关系, 部署情况, 机房分布, 降级策略, 容灾方案, 备用方案

一些具体 case 的压测方法

测试数据准备

高质量的测试数据应当能真实的反映用户的使用场景,我们一般会选择以线上真实数据作为数据源,经过采样、过滤、脱敏,作为性能测试的测试数据。但是在拿真实数据测试之前,必须要先线下模拟测试数据,至少先验证整个系统的基本性能需求后才能拿真实数据做性能测试。

存储层(数据库和缓存)的压测方法

针对无状态服务的话,要提高并发能力很容易,可以无脑扩容。但是针对有状态的存储系统,它能支持的最大并发数不是可以无限扩展的,因此我们一定要能够清楚我们的数据存储层能抗多少量,而针对这种存储集群的压测,一般就是:

  • 首先针对单机进行压测
  • 然后再去分析,集群的整体抗量能力,需要注意,集群能够承载的量不是单机的累加值,一般在集群中每增加一台机器,可以采用 80% 递减的方式来粗略评估。
  • 最后需要注意,集群的整体抗量能力需要根据实际情况去达到一个合理的配置,并不是集群中的机器越多越好。压到一个符合预期的值即可。

文转载自微信公众号「 后端系统和架构」,作者「 AllenWu」,可以通过以下二维码关注。

转载本文请联系「后端系统和架构」公众号。

责任编辑:武晓燕 来源: 后端系统和架构
相关推荐

2022-06-27 08:47:29

BEM修饰符元素

2015-03-27 09:31:01

2013-12-25 09:50:27

华为马悦企业业务

2023-11-20 07:10:48

用户分析聚类算法

2024-08-28 11:03:52

2017-04-06 15:20:24

互联网性能容量

2017-06-27 13:50:37

数据分析Session

2022-11-25 18:49:11

云原生

2020-04-02 07:55:07

分析方法论研发

2016-12-01 19:10:42

大数据数据分析

2016-09-07 14:41:43

数据分析数据分析方法论

2015-06-17 10:34:15

SQL Server性能调优

2009-03-16 13:43:14

2021-11-05 08:28:27

内存泄漏调试

2020-10-12 07:57:42

技术架构制图

2024-06-12 10:59:34

测试自动化软件开发

2015-08-12 17:06:28

2022-08-22 11:45:59

架构技术

2014-04-21 10:38:36

大数据

2021-05-20 09:00:00

数字化转型IT技术
点赞
收藏

51CTO技术栈公众号