性能测试瓶颈分析与系统调优(4)jmetrer+influxdb+grafana性能测试

3.3性能测试领域概念细分

基准测试：理论推断

负载测试：实际性能数据（小规模）

基准测试和负载测试目的：探索程序的负载能力

压力测试：取负载测试结果中最高的负载能力-压

取超过预期负载的测试没看程序的性能反应

耐久性测试（疲劳测试）测试时长，取决于业务场景

尖峰测试：模拟突然出现的高并发负载

压力，耐久，尖峰测试目的，是为了探索程序在负载情况下的反应

3.4jmeter性能测试技巧

csv文件驱动：jmeter读取csv文件数据，为一行一行循环读取，单线程和多线程 读取一致

固定定时器：用，通过Thread Dela设定每个线程请求之前的等待时间（单位为毫秒）。注意：固定定时器的延时不会计入当前smmpler的响应时间里，但是会计入事务控制器的时间。对于事务控制器来说，定时器相当于loadrunner中的think time(思考时间：实际操作中 ，模拟用户在操作过程中的等待时间）

高斯随机定时器：如果需要每个线程的延迟时间是符合正态分布的随机时间停顿，那么使用这个定时器，总延迟=高斯分布值（平均0.0和标准偏差1.0）*指定的偏差值

（Math.abs((this.rabdom.next.nextGaussian()*偏差值)+固定延迟偏移值))

均与随机定时器：和高斯随机定时器的作用差异不大，它产生的延迟时间是个随机值，而各随机出现的概率均等。总的延迟时间等于一个随机延迟时间加上一个固定延迟时间，用户可与设置随机延迟时间和固定延迟时间

同步定时间：用来设置集合点，其作用是：阻塞线程，直到指定的线程数量到达后，再一起释放，可以瞬间产生很大的压力

Number of simulated Users to Group by :模拟用户的数量，即指定同时释放的线程数量，若设置为0，等于设置为线程中的线程数量

Timeout in milliseconds：超时时间，即超市多少毫秒后同时释放指定的线程数，如果设置为0，该定时器将会等待线程数达到可设定的线程数量才释放，若没有达到，一直死等。如果大于0，那么如果超过Timeout in milliseconds始终设定的最大等待时间后，还没有达到设置的新成熟，timer将不在等待，释放已达到的线程，默认为0

同步定时器（synchronizing time)的超时设置要求：超时时间＞请求集合数量*1000(线程数/线程加载时间）

固定吞吐量定时器：

Target throughput(in samples per minute)：目标吞吐量

This thread only：设置每个线程的吞吐量。总的吞吐量=线程数*该值

all active threads in current thread group:吞吐量被分摊到当前线程组所有的活动线程上。每个线程将根据上次运行时间延迟

all act threads :吞吐量被分配到所有线程组的所有活动线程的总吞吐量。每个i安城将根据上次运行时间延迟。在这种情况下，每个线程组需要一个具有相同设置的固定吞吐量定时器（不常用）

all active threads(shared):同上，但每个线程组是根据线程的上次运行时间来延迟。相当于让所有线程组整体排队（不常用）

精准吞吐量定时器：

Target Throught:目标吞吐量

Throught Period:表示在多长时间内发送Target Throught指定的请求数（以秒为单位）

Test Druation:指定测试运行 时间（以秒为单位）

Number of threads in the bath:用来设置集合点，等到指定个数的请求后并发执行

泊松随机定时器：这个定时器在每个线程请求之前按随机的时间停顿，总的延迟就是泊松分不值和偏移值之和(需要了解数学里面的“泊松分布”这个概念

Debug调试器，查看jmeter变量及属性

Jmeter执行机器端口被占用

Data type(“text”|”bin”).texy

Response code:Non HTTP response code:java.net.BindException

Response message:Non HTTP response message:Address already in use:connect

每次网络调用，需要占用机器段端口（不论是客户端还是服务段）

服务器的端口数量：6w多个，65536固定的

所以每个机器能够模拟的并发是有限的

性能测试需要单独的机器去执行脚本，如果是大并发，脚本执行的机器配置本身就要足够好，甚至是分布式集群压测

3.5性能测试方案结构

测试简介

测试实施情况

测试结果

测试结论

详细分析报告

3.5服务器资源监控体系搭建

3.5.1 nmon安装 部署

nmon官网下载地址：https://nmon.sourceforge.net/pmwiki.php?n=Main.HomePage

下载liunx监控插件，选择 Download Binaries，选择任意后缀为.tar的文件

这里我们下载16d版本

注：该软件用来监控服务器资源的，所以应该状态;liunx应用服务或liunx数据库等需要进行监控资源的服务器上，而非装在jmeter监控服务器上

下载完成后，将文件上传到某个目录下：

mkdir /reading/nmon #在reading目录下创建一个nmon文件夹

tar -zxvf nmon16m_helpsystems.tar.gz -C /reading/nmon #解压文件到nmon目录中

cd /reding/nmon #进入到nomon解压后的目录中

如果你的虚拟机内核是centos7，则将nmon_x86_64_centos7复制到移动到/usr/bin目录下,方便以后在任何目录下进行运行

mv nmon_x86_64_centos7 /usr/bin/nmon #移动到usr/bin目录下，重命名为nmon

执行nmon命令，启动

c : 显示cpu利用率数据

m：显示内存数据

n：显示网络信息

d：显示磁盘信息

t：系统进程信息

h：查看帮助信息

q：退出Nmon界面

命令展示是实时的情况，没法去统计到一段时间内资源的变化

为了配合性能测试，我们往往需要将一段时间内的系统资源消耗情况记录下来

运行命令的时候，指定让他输出到某个具体的位置

创建一个临时文件夹：mkdir /reading/nmom_logs

运行nmon -f -N -m /reading/nmon_logs -s 30 -c 120

-f按照标准格式输出文件：

-N include NFS sections

-m 切换到路径去保存日志文件

-s 每个多少秒抽样一次，这里为30s

-c 抽取多少个取样数量，这里为120，即监控=120*（30/60/60）=1小时

根据小时计算这个数字的公式为：c=h*3600/s,比如要监控10小时，每个30s采样一次，则：c=10*3600/30=1200

这个命令运行之后，后台运行，停止数据采集

ps -ef |grep nmon

kill -9 进程ID

3.5.2 nmon数据分析

通过工具进行可视化展示，一般可以使用nmonchart 和nmon_analyser

在官网都可以下载到，比较落后的一种方式，简单讲一下nmon_analyser

部分公司可能还在使用这种方式，将liunx /reading/nmon_logs下运行记录nmon文件，下载到window主机上，解压打开nmon_analyser压缩包里面的nmon analyser v69_2.xlsm文件

注：这里不要使用wps,wps vba宏是被禁用的，需要付费，1年365元，开通以后，下载vba宏才生效，直接下载vab宏，安装也会报错，公司如果使用的是这种方式，用windos自带的office，不当韭菜。

注意实现：不是有所的公司都提供额外的服务让你去搭建监控看板的，后续在做品瓶颈分析的时候，需要命令去做仔细的排查。

缺点：nmon单价监控，集群不方便，有条件，一定是集群式的监控体系

缺点2：不方便实时监控

3.6基准、负载、压力、尖峰测试

3.6.1基准测试

这里设置一个线程，压测60s，查看结果分析

在1分内，累计发起总请求数：75151个请求，接受字节795MiB,发送字节数量8MiB

其中：总吞吐量：最低1.05K,最大为1.33K,平均1.25K，总错误0，活动线程数量1

在系统没有压力时，单线程产生的并发量=1000ms/单个接口响应时间

这里首页整体的平均响应时间大概为7ms,则单个接口的并发为：1000/7=142

线程数量=目标并发量/单个线程并发量

理论：我们的并发量为5000/s，则大致的线程数量为：5000/142约等于35，即用35个线程数，可以模拟达到5000并发/s

3.6.2负载测试：

设置35线程数，采用梯度压测的手法，对服务进行负载测试，找到系统的最大 处理能力

This group will start Max threads 总线程数：35

First,wait for N seconds 启动第一个线程数需要等待多少秒设为：0

Then start 设置最开始时，启动的线程数量：设为0

Next add：增加线程数量，设为2

threads every 每个多少秒：设为5

using ramp-up 在多少秒内启动多少个线程，设为10

Then hold load for 启动的线程总数达到Max之后，运行多少秒，设为30

Finally，stop：关闭线程数5

threads ervery 每个多少秒，设为1

设置总线程数35，初始线程为0，启动第一个线程需要等待0s，接下来在10s内没5秒启动1个线程数，在总线程数量达到5个时，运行30s，最后每1秒关闭2个线程数

这里通过负载测试，我们看到系统的的吐量为平均为1120b/s

查询一下这个时间段

3.6.3压力测试

通过负载测试，找到系统的最佳处理能力，然后进行长时间的压力测试，测试系统在持续是否可以一直持续稳定的运行，找到系统的崩溃时间点。目的:系统在高压情况，是否能在短时间内，继续持续稳定运行，能不能自己恢复，运行了多久会崩，找到这个时间点长，让负责人，在这段时间进行处理紧急修复。

3.6.3尖峰测试：

这里使用线程组：jp@gc - Ultimate Thread Group

Start Threads count ：总线程数

Iiitial DELAY，sec ：延迟多少秒启动

Startup time，sec :多长时间内启动这些线程数

Hold load For，sec :持续运行多长时间

Shutdown time，多长时间 关闭这些线程数

为什么要做这个测试，真实的用户场景，有可能突然达到系统2倍，乃至3倍的突然当量用户访问系统。测试应用程序的处理情况，能不能恢复过来。

这里我的电脑：相对并发数3，分别设置了3组线程

第一组：模拟3个用户，立即启动，1秒内启动这三个线程数，持续运行120s，5s关闭

第二组：延迟10秒，在1s内，立即启动6个用户，此时线程数量达到了 9个，持续运行120s，5s关闭。

第三个：延迟20秒，在1s内，立即启动9个用户，此时宗宪成数量达到了18，持续运行120s，5s关闭。

负载、压力、尖峰根据系统的业务程序，不可能就几秒钟，这里简单写个文档，不会去持续压测很长时间。