更多优质内容
请关注公众号

Nginx优化篇 ab压力测试和监控 (二十二)-张柏沛IT博客

正文内容

Nginx优化篇 ab压力测试和监控 (二十二)

栏目:其他内容 系列:Nginx入门系列 发布时间:2020-02-18 12:22 浏览量:2884

ab压力测试和监控

 

1.测试环境准备

在开始测试前先查看系统CPU,内存,带宽:  

  

#查看逻辑CPU个数
cat /proc/cpuinfo | grep "processor" | wc -l      # 1

#查看内存
free -m           # 1838M,约为2G

#查看网卡带宽
ifconfig                 #获取网卡名字,得到eth0;这里要根据你的系统的情况来看,可能你的系统网卡名不是eth0
ethtool eth0        #查看eth0网卡带宽,1M/s

 

 

 

2.ab压力测试工具安装和使用:

Apache 服务器自带的一个 web 压力测试工具 ApacheBench ,简称 ab。ab 是一个命令行工具,即通过 ab 命令行,模拟多个请求同时对某一 URL 地址进行访问,因此可以用来测试目标服务器的负载压力。

如果安装了Apache,则系统自带这个命令。如果没有安装Apache,也可以安装httpd-tools包,安装后就有ab工具了。

yum install httpd-tools

 

建议ab压力测试的客户端和服务端不要在一台机器上。

 

ab命令最常用的3个参数:

-c:一次并发请求的数量;
-n:请求总次数
-k:使用HTTP的KeepAlive特性

基本上会这3个参数就够用了。

 

ab测试结果的含义

Server Software:        nginx/1.14.2
Server Hostname:        www.zbpblog.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:          /
Document Length:        41909 bytes

Concurrency Level:      10
Time taken for tests:   38.391 seconds           **
Complete requests:      100                      **
Failed requests:        0                        **
Total transferred:      4207200 bytes
HTML transferred:       4190900 bytes
Requests per second:    2.60 [#/sec] (mean)      **
Time per request:       3839.115 [ms] (mean)     **
Time per request:       383.912 [ms] (mean, across all concurrent requests)    **
Transfer rate:          107.02 [Kbytes/sec] received    **

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      662 1182 945.1    749    7755
Processing:   480 1499 1085.4   1224    6152
Waiting:      471  782 446.6    546    2655
Total:       1181 2681 1454.4   2344    8565

Percentage of the requests served within a certain time (ms)
  50%   2344
  66%   2966
  75%   3272
  80%   3511
  90%   4121
  95%   6309
  98%   8130
  99%   8565
 100%   8565 (longest request)

PS:标了**的项要重点关注

 

主要看几个重要的:
# 并发的请求量
Concurrency Level:      10

# 总的请求数
Complete requests:      100

# 失败的请求数
Failed requests:        0

# 测试所花的时间,越长说明性能越差
Time taken for tests:   38.391 seconds

# *平均每秒的响应请求数(返回了响应的请求数),也是我们经常看到的吞吐量(QPS)。我们可以理解为服务器每秒可以处理的请求数。
# QPS = 总请求数/(进程总数*总请求时间)
Requests per second:    2.60 [#/sec] (mean)
在这里 QPS = 100/38.391 = 2.6

# 在指定并发请求下(这里是10个并发请求)处理一个请求花费的平均时间。
Time per request:       3839.115 [ms] (mean)

# 单个用户请求一次的平均时间
Time per request:       383.912 [ms] (mean, across all concurrent requests)

# 传输速率,单位:KB/s
Transfer rate:          107.02 [Kbytes/sec] received

# 百分之多少的请求的响应时间少于多少毫秒
  75%   3272    # 75%的请求的响应时间小于3秒

上面的测试中:总请求数为100个,并发请求10个。意味着客户端发起了10条TCP连接连向服务端的443端口(因为是https)。
每个连接同时发送1个请求就可以达到保持10个并发请求。

 

如果使用-k参数,表示客户端使用keepalive连接。每个一个连接可以传输多个http请求,多个http请求可以复用一个连接。

关于QPS和PV:
PV:访问量,刷新一次会加一
UV:客户端个数
IP:独立ip个数
QPS:每秒平均的能处理请求的个数

如果用一台电脑打开2个不同的浏览器,每个浏览器访问5次:
IP 1个
UV 2个
PV 10个

 

3.iftop命令监控带宽使用情况

安装iftop

yum install -y iftop

或者

apt-get iftop

 

使用命令:

# 默认是监控第一块网卡的流量
iftop

# 监控eth1
iftop -i eth1

# 直接显示IP, 不进行DNS反解析
iftop -n

# 显示某个网段进出封包流量
iftop -F 192.168.1.0/24 or 192.168.1.0/255.255.255.0

 

显示结果:

框1:本机

框2:记录了哪些ip正在和本机的网络连接

=>代表发送数据,<= 代表接收数据

中间部分右边:实时参数分别是该访问ip连接到本机2秒,10秒和40秒的平均流量

框3:

TX:发送流量(服务器返回响应使用的流量)
RX:接收流量 (服务器接收请求接收的流量)
TOTAL:总流量
Cumm:运行iftop到目前时间的总流量
peak:流量峰值
rates:分别表示过去 2s 10s 40s 的平均流量

 

我们主要关注 框3 中的TX的peak值和rates值,即主要关注发送出去的流量的峰值和平均值。如果这个值到达了系统的带宽上限,也就是带宽跑满了之后,即使系统的CPU和内存足以处理高并发请求,也会因为带宽的限制导致响应返回给客户端的速度很慢。结果就是客户端访问页面响应时间很长。

此时解决办法只有提高带宽。

我的系统是1M带宽,对于php请求,在并发请求达到几十的时候,带宽就已经跑满了。流量峰值最多不超过5M,均值不超过3M,多数在1~2M之间,但是很明显这是不够的。

 

总结:主要查看peak和rates值是否已经达到带宽上限。

 

4.测试过程中的数据监控

* 查看cpu使用、内存、进程总体情况

top

 

* 查看带宽使用情况

iftop

 

* 使用nginx的stub_status查看nginx的连接和请求处理情况

使用stub_status,并建立服务

 

 查看系统总连接数:

netstat -nat | wc -l

 

查看某端口连接数

netstat -nat | grep 端口号 | wc -l

 

查看php-fpm的进程数,处于运行状态的进程数

ps -aux|grep php-fpm|wc -l

ps -aux|grep php-fpm|awk '{if($8~"R") print}'|wc -l

PS:如果所有fpm的worker进程处于运行状态的进程数没有达到你在php-fpm.conf的值,且CPU和内存没跑满的情况下,就说明你的系统在这个数量的高并发下还行有余力。

 

查看处于time_wait状态的tcp连接

netstat -an | grep -i time_wait

netstat -an | grep -i time_wait | wc -l

PS:如果处于time_wait的socket数量很多,是非常不利于高并发连接的,因为time_wait状态的连接已经停止发送请求,却还一直占用着端口,还连着服务器,数量过多会使其他新连接连不上服务器。

 

最后还可以在高并发测试过程中,直接打开网站看看是否响应时长很长,这样可以最直观的感受系统是不是能承受这么多的高并发连接和请求。

 

下一节,我们正式开始进行压力测试。

 




更多内容请关注微信公众号
zbpblog微信公众号

如果您需要转载,可以点击下方按钮可以进行复制粘贴;本站博客文章为原创,请转载时注明以下信息

张柏沛IT技术博客 > Nginx优化篇 ab压力测试和监控 (二十二)

热门推荐
推荐新闻