性能测试基础和分布式压测原理

性能测试流程

性能测试术语

响应时间 RT（Response Time）：对请求作出响应所需要的时间

网络传输时间：N1+N2+N3+N4
应用服务器处理时间：A1+A3
数据库服务器处理时间：A2
响应时间=N1+N2+N3+N4+A1+A3+A2

吞吐量

吞吐量的计算公式 指单位时间内系统处理用户的请求数

从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量

从网络角度看，吞吐量可以用：字节/秒来衡量

对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力 以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制 约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。 当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，

可以采用以下公式计算：F=VU* R / 其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间

jmeter中****throughput的计算方式

思考时间（Think Time），也被称为休眠时间，从业务的角度来说，该时间指的是用户在进行操作时，每个请求之间的间隔时间。前面已经讨论过，对交互式应用来说，用户在使用系统时，不大可能持续不断地发出请求，更一般的模式应该是用户在发出一个请求后，等待一段时间，再发出下一个请求。

术语表

性能测试场景

性能工程相关法

帕累托法则

帕累托法则，它也被称为 80/20 法则、关键少数法则，或者八二法则。

利特尔法则

这个法则描述的是：
在一个稳定的系统中，长期的平均客户人数（N）等于客户抵达速度（X）乘以客户在这个系统中平均处理时间（W），也就是说 N=XW。

假定我们所开发的服务器程序可以进行并发处理，同时处理多个客户请求。并发的客户访问
速度是每分钟到来 1000 个客户，每个客户在我们的服务器上花费的平均时间为 2 分钟。

假定我们所开发的服务器程序可以进行并发处理，同时处理多个客户请求。并发的客户访问速度是每分钟到来 1000个客户，每个客户在我们的服务器上花费的平均时间为 2分钟。根据利特尔法则，在任何时刻，我们服务器系统里面将容纳 1000×2=2000个客户。这2000个客户都在被服务。

过了一段时间，由于客户群的增大，并发的访问速度从每分钟 1000 客户增大到每分钟2000个客户。在这样的情况下，我们该如何改进我们系统的性能来应对呢?

根据利特尔法则，我们可以有两种方案来解决这一需求。

第一种方案是把客户的处理时间减半，从2分钟减到1分钟。这样我们的系统容量可以不变，客户滞留在我们系统的时间减半，刚刚好可以活应访问速率加倍的要求。系统容量就等于 2000客户每分钟乘以1分钟，还是 2000个客户。
第二种方案是扩大系统容量，维持处理时间不变。因为客户访问速度加倍了，所以系统容量也需要加倍，变成 4000。假如原来的系统需要 500 台服务器，那么新系统就需要 1000 台服务器。

阿姆达尔定律

分布式压测原理

为什么要做分布式？

Jmeter 局限性
● A single JMeter client running on a 2-3 GHz CPU (recent CPU) can handle 1000-2000 threads depending on the type of test.
● 由于 Jmeter 启动大量线程，对 CPU 和内存的消耗较大，在需要模拟大量并发用户数时，单机压测会导致测试脚本本身达到瓶颈

因为单机无法支撑数以万计大并发，此时，需要多个压力机进行分布式压力测试，这样性能瓶颈就不会是我们的压力机了
联想场景
● 测试 10000 并发的场景，但单机只能支持 1000 并发无法达到 10000
● 通过分布式（10 台Slave机器）可以模拟 10000 并发
分布式压测
Jmeter 支持分布式压测，将需要模拟的大量并发用户数分发到多台压力机，使 Jmeter 拥有更大的负载量，满足真实业务场景（高并发场景）
分布式的最终目的
● 确保压测过程中性能瓶颈不出现在压力机上

jmeter分布式工作原理

控制器节点
运行 JMeter GUI 的系统，它控制测试
工作节点
运行jmeter-server的系统，它从 GUI 获取命令并将请求发送到目标系统
目标
我们计划进行压力测试的网络服务器

目前压测环境分布式压测架构

​​​​​​​

上面的图看完就懂了，原理如下：

1. Controller 是控制机，Worker是多个压力机
2. 分布式测试中，Controller 通过命令行将测试脚本分发给所有 Worker
3. Worker不需要启动 Jmeter GUI，通过 CLI 模式执行测试
4. Worker 执行完后，会把结果回传给 Controller
5. 异步监听 Worker 的结果并写入influxdb集群
6. 如果测试结果数据量过大influxdb集群撑不住，可以异步发送到kafka集群再同步influxdb集群