php fpm 测试,Nginx优化篇 nginx+php-fpm压力测试实践 (二十三)

最新推荐文章于 2022-03-01 09:39:59 发布

牛学霸秒懂训练营

最新推荐文章于 2022-03-01 09:39:59 发布

阅读量523 php fpm 测试

压力测试环境准备：

系统：Linux Ubuntu 16.04.4

CPU核数：2

内存：2G

带宽：10000M/s

服务端：Nginx 1.16 + php-fpm 7.2

客户端：一台带宽50M/s的服务器。客户端的带宽不能太低。

连接监控：nginx的stub_status模块

配置参数如下：Linux内核参数：

net.ipv4.tcp_syncookies = 1

net.ipv4.ip_local_port_range = 10240 60999

net.ipv4.tcp_max_syn_backlog=10240

net.core.somaxconn=10240

net.core.netdev_max_backlog=20480

net.ipv4.tcp_tw_reuse=1

net.ipv4.tcp_max_tw_buckets=5000

net.ipv4.tcp_fin_timeout=30

# /etc/security/limits.conf (ulimit)

* soft nofile 100001

* hard nofile 100002

root soft nofile 100001

root hard nofile 100002

wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

nginx配置：

worker_processes auto; #

worker_cpu_affinity auto; #

worker_rlimit_nofile 65535; #

worker_priority -19; #

events {

worker_connections 1024; #

use epoll; #

}

http {

include mime.types;

default_type application/octet-stream;

tcp_nodelay on; #

log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"';

sendfile on; #

keepalive_requests 1000; #

keepalive_timeout 30; #

gzip on; #

gzip_min_length 20k; #

gzip_comp_level 2; #

gzip_types image/jpeg image/gif image/png;

server {

server_name www.atfxnews.com atfxnews.com;

root /var/www/atfxnews/public;

index index.html index.htm index.php;

listen 80 backlog=1024; #

#rewrite ^(.*)$ https://www.atfxnews.com permanent;

location / {

if (!-e $request_filename) {

rewrite^(.*)$ /index.php$1 last;

}

location ~ \.php {

proxy_http_version 1.1; #

proxy_set_header Connection ""; #

fastcgi_index index.php;

fastcgi_pass 127.0.0.1:9000;

fastcgi_split_path_info^(.+\.php)(.*)$;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

fastcgi_param PATH_INFO $fastcgi_path_info;

include fastcgi_params;

}

server {

server_name www.atfxnews.com atfxnews.com;

listen 443 backlog=1024 ssl; #

root /var/www/atfxnews/public;

index index.html index.php index.htm;

ssl_certificate /var/www/ssl/Apache/2_www.atfxnews.com.crt;

# ssl_certificate /var/www/ssl/Apache/zbp_chain.crt;

ssl_certificate_key /var/www/ssl/Apache/3_www.atfxnews.com.key;

location / {

if (!-e $request_filename) {

rewrite^(.*)$ /index.php$1 last;

}

location ~ \.php {

proxy_http_version 1.1; #

proxy_set_header Connection ""; #

fastcgi_index index.php;

fastcgi_pass 127.0.0.1:9000;

fastcgi_split_path_info^(.+\.php)(.*)$;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

fastcgi_param PATH_INFO $fastcgi_path_info;

include fastcgi_params;

}

include conf.d/*.conf;

}

wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

标记了#的地方是优化项

php-fpm配置：

listen = 127.0.0.1:9000

listen.backlog = 10240

process.priority = -19

pm = static # 静态模式

pm.max_children = 100 # 因为是2G内存，按每个worker进程会消耗20M内存，分配1600M内存给worker进程，400M留给其他程序

# pm.min_spare_servers = 5

# pm.max_spare_servers = 65

pm.max_requests = 1000

slowlog = /var/log/php-fpm/www-slow.log

rlimit_files = 10240

wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

正式测试

测试动态页面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限制。