压力测试环境准备:
系统:Linux Ubuntu 16.04.4
CPU核数:2
内存:2G
带宽:10000M/s
服务端:Nginx 1.16 + php-fpm 7.2
客户端:一台带宽50M/s的服务器。客户端的带宽不能太低。
连接监控:nginx的stub_status模块
配置参数如下:Linux内核参数:
nginx配置:
标记了#的地方是优化项
php-fpm配置:
正式测试
测试动态页面1: 10个并发请求,100个总请求,请求类型为动态请求php
ab -c10 -n100 -k https://www.atfxnewx.com/
结果如下:
服务端消耗的带宽:平均2.6M/s
CPU消耗:30%
处于运行状态的php进程数:1~2个
nginx连接数:15个左右
吞吐量:8
100个请求的总响应时间:13.3s
在10的并发请求下,平均一个请求的响应时间为:1.3s
100个请求的失败请求数:0
并发过程中在浏览器直接访问网站:流畅
结论:在10个并发请求下,CPU没有跑满,说明服务器的压力不大,行有余力;平均响应时间1.3秒,对于访问一个门户网站的首页而言,用户体验较好。
测试动态页面2: 100个并发请求,1000个总请求,请求类型为动态请求php
ab -c100 -n1000 -k https://www.atfxnewx.com/
结果如下:
服务端消耗的带宽:平均14M/s
CPU消耗:76%
处于运行状态的php进程数:最高25个
nginx连接数:最高100个
吞吐量:32
1000个请求的总响应时间:31s
在100的并发请求下,平均一个请求的响应时间为:3.1s
1000个请求的失败请求数:11
并发过程中在浏览器直接访问网站:较为卡顿
结论:在100个并发请求下,CPU占用76%,说明服务器的压力也还行;平均响应时间3.1秒,说明在100的并发下(相比于10并发),响应时间明显加长,用户体验下降;吞吐量较10个并发的时候大幅增加,说明随着并发量的增加,服务器的处理能力开始展现;带宽使用也大幅增加,这是因为相同时间内处理的请求数增加,因此返回的响应数量也增加,发送给客户端的数据流量增大了。
测试动态页面3: 200个并发请求,2000个总请求,请求类型为动态请求php
ab -c200 -n2000 -k https://www.atfxnewx.com/
结果如下:
服务端消耗的带宽:平均16M/s
CPU消耗:87%
处于运行状态的php进程数:最高43个
nginx连接数:最高162个
吞吐量:50
2000个请求的总响应时间:40s
在200的并发请求下,平均一个请求的响应时间为:4s
2000个请求的失败请求数:18
并发过程中在浏览器直接访问网站:较为卡顿
结论:在200个并发请求下,CPU占用87%,说明服务器压力山大;平均响应时间4秒,,响应时间明显加长;吞吐量较100个并发的时候又有增加(32->50),说明100并发下还不是极限,服务器还能承受比100更大的并发请求;带宽略微增加。
测试动态页面3: 500个并发请求,5000个总请求,请求类型为动态请求php
ab -c500 -n5000 -k https://www.atfxnewx.com/
结果如下:
服务端消耗的带宽:平均16M/s
CPU消耗:88%
处于运行状态的php进程数:最高39个
nginx连接数:最高450个
吞吐量:51.5
5000个请求的总响应时间:97s
在500的并发请求下,平均一个请求的响应时间为:9s
5000个请求的失败请求数:41
并发过程中在浏览器直接访问网站:9秒响应一个页面,已经很慢了
结论:在500个并发请求下,CPU占用、带宽消耗和吞吐量和200相比几乎没有变化,说明在并发为200时就已经是服务器的极限(极限很可能并发比200更小,因为500并发比200并发的CPU基本没变化,说明87%,88%的CPU占用已经达到最高,可是200并发的时候,CPU已经达到最高)。带宽消耗没变化是因为请求的处理已经达到极限,但相比于10000M/s的带宽上限来说还是远远没有利用全。
我们最重要的关注2个值:
A. 并发请求下,平均一个请求的响应时间。
B. 吞吐量(QPS),即一秒内能处理并返回了响应的请求
前者影响着用户的访问体验
后者体现了服务器处理请求的能力
php-fpm改为动态模式,并设置
max_children=128,
max_spare_servers=80,
min_spare_servers=10,
start_servers=50
再尝试500并发的请求,然而结果没有改变。
看了还是受到了CPU限制。