rhythm-2019 / api-monitor Goto Github PK

并发数

并发数是指存在多少个客户端同时使用当前系统，每一个客户端都会与服务端进行 TCP 连接，消耗系统的连接数（Tomcat 等 Web 应用程序可以配置，连接由操作系统维护，消耗操作系统内存）。

服务端应用程序一般会使用线程池处理多个连接发送过来的数据，线程池中的线程数也可以配置，也是有讲究的：

• CPU 密集型应用：线程数应该等于 CPU 核心数 + 1
• IO 密集型应用：线程数应该等于 CPU 核心数 * 2

上面两个是经验值，计算方式如下：

公式一：Nthreads = Ncpu x Ucpu x (1 + W/C)

Ncpu 是 CPU 核心数，Ucpu 是期望 CPU 到达的占用率，W/C 为等待时间/请求时间（固定值，可以测出）

公式二：Nthreads = Ncpu / (1 - 阻塞系数)

阻塞系数等于 阻塞时间 / (计算时间 + 阻塞时间)，其实就是公式一中的 W/C，计算越密集阻塞系数越小，IO 越密集阻塞系数越大

N + 1 和 2N 来源解释：

1. N + 1：CPU 密集型应用，根据公式二阻塞系数为 0，分母趋近于 1，由于 CPU 在计算过程中可能访问到需要换页的内存，需要发生缺页中断，多出一个空闲 CPU。
2. 2N：IO 密集型应用，根据共十一 W/C 趋近于 1，Ucpu 期望为 100%，结果为 2N

实际例子：
问：8核CPU，一次请求计算花费 5ms，访问 DB 需要花费 100ms，请问线程数设置为多少比较合适？
答：对于一颗 CPU，目前的占用率是（5/105 * 100%），我们希望使用多线程让 CPU 占用率到达 100%，所以需要设置 （100%）/（5/105 * 100%），最后乘核心数即可。但实际还要考虑内存大小等因素才会有上面两条经验公式

线程数量过多会导致虚拟机栈或者堆内存溢出。

# 在配置文件中添加如下内容
# tomcat最大线程数，默认为200
server.tomcat.max-threads=200
# tomcat最大连接数，默认为10000（网上的说法）
server.tomcat.max-connections=300

所以采集 IO 时间、当前连接数是比较关键的

吞吐量

单位时间内系统能够处理的请求数量，是主要的性能指标，TPS 和 QPS 是他的量化标准

响应时间（RT）

指执行一个请求从开始到最后收到响应数据所花费的总体时间,即从客户端发起请求到收到服务器响应结果的时间，也是一个重要的指标，也应该从外部测试

QPS(Queries Per Second)

是每秒查询率，是一台服务器每秒能够相应的查询次数，即1秒内完成的请求数量，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

峰值 QPS（预估指，用于预估需要多少台机器）：计算峰值QPS，80%的请求集中在20%的时间，峰值 QPS = (总 PV 数 * 80%) / (每天秒数 * 20%)。需要的机器 = 峰值 QPS / 实际单机的 QPS

单机实际 QPS：jmetter 得知一个接口平均响应时间为 80ms，那么一秒钟可以处理 1000ms/80ms 个请求，所以单机实际 QPS 为 12.5。

加入多个线程可以让实际 QPS 翻倍，但是根据上面的理论线程数不能无限增长，线程数量越多需要的内存越大，CPU 上下文切换越频繁。

PV：Page View 每个页面的访问次数
UV：Unique View：每个客户端的访问次数
IP：Internal Potocol，每个 IP 的访问次数

TPS(TransactionsPerSecond)

也就是事物数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数

TPS 和 QPS 的区别？
比如一次页面的请求访问，可能会对多个服务器产生多个请求，TPS 关注所有请求，QPS 关注单个服务的请求

用户体验相关参数：http://www.alloyteam.com/2020/01/14184/

ABTest 压测结果参数解释

我们可以用 abstet 对接口进行压力测试

$ sudo apt-get install apache2-utils
$ ab -n100 -c 10 http://xxx

返回的结果中有几个核心数据

• Requests per second: 19.66 [#/sec] (mean)
  吞吐率中的 QPS，大家最关心的指标之一，相当于 LR 中的每秒事务数，后面括号中的 mean 表示这是一个平均值

• Time per request: 5087.180 [ms] (mean)
  用户平均请求等待时间，整个测试的时长 / 总请求个数

• Time per request: 50.872 [ms] (mean, across all concurrent requests)
  这个才是平均 RT，服务器平均请求处理时间，大家最关心的指标之三

两个 Time per request 的区别，比如我在在一次测试中花费了 90ms，发送了三个请求，分别耗时 30、40、50ms，第一个 Time per request 是 90/3，第二个 Time per request 则是 (30 + 40 + 50) /3

在哪个位置采集什么指标

请求链路：客户端（探针、网关、用户浏览器、压测工具） -> 上游服务器

• 服务端：需要采集线程数、连接数、请求处理时间、HTTP Status Code、PV 等
• 客户端：需要采集用户体验参数、RT、

借助上面的指标可以聚合出 QPS、mean RT、99%RT、999%RT

参考：https://www.jianshu.com/p/31afb8492eff