虚心使人进步

虚心学习,天天向上......
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

设置PHP最大连接数及php-fpm -static高并发+ab测试

Posted on 2024-02-26 22:02  Showker  阅读(519)  评论(0编辑  收藏  举报

设置PHP最大连接数及php-fpm 高并发 参数调整

 

服务器中找到php-fpm.conf配置(有的会在引入的www.conf中)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[global]
pid = /usr/local/php/var/run/php-fpm.pid
error_log = /usr/local/php/var/log/php-fpm.log
log_level = notice
 
[www]
listen = /tmp/php-cgi.sock
listen.backlog = -1
listen.allowed_clients = 127.0.0.1
listen.owner = www
listen.group = www
listen.mode = 0666
user = www
group = www
pm = static
pm.max_children = 200
pm.start_servers = 40
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.max_requests=1000
request_terminate_timeout = 100
request_slowlog_timeout = 0
slowlog = var/log/slow.log

  

---------------------------------------------------------------------------

1
2
3
4
pm.max_children=30
pm.max_requests=500
pm.start_servers=4
pm.max_spare_servers=30

  

一. pm= static

首先说一下pm这个值   pm = dynamic 这个是php的进程数是动态的  会根据访问量来确定来回增加

而在高负载的php环境下我推荐设置  pm= static php-fpm进程数固定

二.  pm.max_children=???

当用静态模式下 进程数确定根据 pm.max_children来进进行确定    那么问题来了我的服务器应该设定多少php-fpm呢 ?

 

    从理论的角度上说php-fpm进程数越多越好,相当于一个酒店有很多个充足的服务员来为你服务肯定会比较爽啊 ,你也不需要等待。

     但是。。。。现实上总是残酷的   php-fpm的进程数会受到你的内存大小的限制。一般情况下我们    进程数 =用机器内存(M)除以2  再除以20(M);

     当然这个也不是绝对的   你需要知道:

  1.  你可以分配给php多大内存 :你的服务器上是不是单纯的php服务器  有没有比较耗费内存的其他程序(mysql)。
  2.  你的每个php-fpm内存占多大 :内存占用多大要根据你的php代码质量和处理的相关业务。当然你可以用命令去统计你的php-fpm平均占用内存大小。

        有人会问我如果设置不恰当会有什么状况出现呢?

     当数值偏小时请求到nginx会无法分配到php-fpm进程 导致502错误

     

     当数值偏大如果没有大访问量还好  如果访问量较大的话 内存都会被php占光了。导致系统响应缓慢   cpu-system  升高 系统不断的去调整内存分配

          严重时会导致较高的 cup-wait 较高   内存不够用了  直接写磁盘  磁盘io直线增加 。cpu使用率也开始爆满。(如图所示)

    

    三.request_terminate_timeout

   计算方式如下:如果你的服务器性能足够好,且宽带资源足够充足,PHP脚本没有循环或BUG的话你可以直接将”request_terminate_timeout”设 置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。

   而如果你做不到这一点,也就是说你的PHP-CGI可能出现某个BUG,或者你的宽带不够充足或者其他的原因导致你的PHP-CGI能够假死那么就建议你给”request_terminate_timeout”赋一个值,这个值可以根 据你服务器的性能进行设定。

一般来说性能越好你可以设置越高,20分钟-30分钟都可以。由于我的服务器PHP脚本需要长时间运行,有的可能会超过10分钟因此我设置了900秒,这样不会导致PHP-CGI死掉而出现502 Bad gateway这个错误。

 

四.pm.max_requests

        这个参数的含义是php-fpm工作进程处理完多少请求后自动重启,主要目的就是为了控制请求处理过程中的内存溢出,使得内存占用在一个可接受的范围内。比较适用于服务器搭载项目比较杂乱,有点请求会比较占用内存

        导致php-fpm占用比较大。在经过一定次数请求后会结束掉进程,释放自己的内存。如果这个值太小就会导致所有的工作进程几乎同时达到这个值并且进入需要重启的状态,当所有的工作进程都在同一时刻重启就会发生在

  数秒内甚至更长的时间PHP将停止响应直到所有的进程均重启完为止。这是不能接受的,所以我一般会把这个值设置为PHP启动后第一批工作进程达到此值需要重启时,第一个进程重启与最后一个进程重启之间的时间相差

  1分钟以上,一般在压力比较大的晚上这个差值将会扩大到5分钟左右,此时对进程重启对服务器的负面影响就可以忽略了。

下面补充几个命令统计相关php-fpm 相关数据  

  

 

1、查看php-fpm的进程个数

ps -ef |grep "php-fpm"|grep "pool"|wc -l

2、查看每个php-fpm占用的内存大小

ps -ylC php-fpm --sort:rss

3.查看PHP-FPM在你的机器上的平均内存占用

ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'

4.查看单个php-fpm进程消耗内存的明细

pmap $(pgrep php-fpm) | less

 重启php-fpm

1
2
3
4
5
6
7
8
9
10
1. 停止命令
  
 pkill php-fpm
  
2.重启或启动命令
  
php-fpm -R
 
/alidata/server/php/sbin/php-fpm
 

概念

吞吐量

系统的吞吐量是指系统的抗压、负载能力,指的是单位时间内处理的请求数量。通常情况下,吞吐率用 “字节数/秒” 来衡量,也可以用 “请求数/秒”,“页面数/秒”,其实,不管是一个请求还是一个页面,本质都是网络上传输的数据,那么表示数据的单位就是字节数。

系统吞吐量的几个重要参数:QPS(TPS),并发数,响应时间等,系统的吞吐量通常由这几个参数值来决定。

吞吐率(Requests per second)

服务器并发处理能力的量化描述,单位是reqs/s,指的是在某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数,称之为最大吞吐率。

记住:吞吐率是基于并发用户数的。这句话代表了两个含义:

a、吞吐率和并发用户数相关

b、不同的并发用户数下,吞吐率一般是不同的

计算公式:总请求数/处理完成这些请求数所花费的时间,即

Request per second=Complete requests/Time taken for tests

必须要说明的是,这个数值表示当前机器的整体性能,值越大越好。

QPS

Queries Per Second,每秒查询数,即是每秒能够响应的查询次数,注意这里的查询是指用户发出请求到服务器做出响应成功的次数,简单理解可以认为查询=请求request

qps = 每秒钟request数量

TPS

Transactions Per Second ,每秒处理的事务数。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。
针对单接口而言,TPS可以认为是等价于QPS的,比如访问一个页面/index.html,是一个TPS,而访问/index.html页面可能请求了3次服务器比如css、js、index接口,产生了3个QPS。

tps = 每秒钟事务数量

并发数

并发数是指系统同时能处理的请求数量,反映了系统的负载能力。

并发数 = 系统同时处理的request/事务数

响应时间RT

Response Time,简单理解为系统从输入到输出的时间间隔,宽泛的来说,代表从客户端发起请求到服务端接收到请求并响应所有数据的时间差。一般取平均响应时间。

QPS,RT,并发数三者关系

QPS = 并发数 / 评价响应时间

一个系统吞吐量通常由QPS(TPS)、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。

ab测试

ab操作说明

介绍

ab是apache bench的简称,是apache提供的压力测试工具。

说明

ab [options] [http://]hostname[:port]/path
options

命令其余请参见 http://apache.jz123.cn/programs/ab.html

发起总请求数:-n

-n1000 //代表本次测试发起1000个请求

请求并发数:-c

-c1000 代表每次都同时发起1000次请求,也就是并发数为1000

本次测试的最大秒速,默认没有限制:-t

-t10 代表10秒后就结束测试

每次请求的超时时间,默认为30:-s

-s30 代表每个请求如果超时30秒,则直接代表该请求超时

包含需要post的文件地址,一般和-T一起使用:-p
POST数据所使用的Content-type头信息:-T

栗子:

ab -c100 -n10000 -p index.txt -T "application/x-www-form-urlencoded"  http://dev.host.net/

index.txt 里面是请求参数:如下

username=choudalao&pwd=123456
显示请求的显示详细程度,默认是只显示上面已完成请求数等:-v

-v1 默认值为1,只显示请求的总统计
-v2 显示响应头,响应数据,并包含1的显示
-v3 显示响应状态码,并包含2的显示
-v4 显示更多信息

-C "cookie1=cookie1,cookie2=cookie2"
以html表格的元素显示ab的测试结果:-w

测试栗子及说明

命令:

ab -c1000 -n100000 http://dev.host.net/

结果:

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking dev.host.net (be patient)
Completed 10000 requests #已经完成的请求数
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        nginx/1.15.11 # nginx 版本(服务器名称)
Server Hostname:        dev.host.net #请求的URL主机名
Server Port:            80 #端口号
# SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256 //SSL/TLS 协议
# TLS Server Name: youxi.test # TLS服务器名
Document Path:          / #请求路径
Document Length:        327 bytes #响应数据长度

Concurrency Level:      1000 #并发数,我们自己设置的-c参数
Time taken for tests:   260.292 seconds #请求完成时间
Complete requests:      100000 #完成请求数
Failed requests:        96673 #错误请求数
   (Connect: 0, Receive: 0, Length: 96673, Exceptions: 0)  
Non-2xx responses:      95644  
Total transferred:      31248236 bytes  #整个场景中的网络传输量
HTML transferred:       16095964 bytes #html响应总长度(去除了响应头的长度)
Requests per second:    384.18 [#/sec] (mean)  #每秒处理的请求数,相当于 LR 中的 每秒事务数 ,后面括号中的 mean 表示这是一个平均值
Time per request:       2602.921 [ms] (mean) #用户平均请求等待时间,相当于 LR 中的 平均事务响应时间 ,后面括号中的 mean 表示这是一个平均值
Time per request:       2.603 [ms] (mean, across all concurrent requests)  #服务器平均处理时间
Transfer rate:          117.24 [Kbytes/sec] received #带宽传输速度,可以帮助排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2  33.0      0     507
Processing:  1006 2556 283.2   2397    4679
Waiting:     1005 1865 454.6   1789    4668
Total:       1008 2559 284.0   2397    4679

Percentage of the requests served within a certain time (ms)
  50%   2397
  66%   2842
  75%   2864
  80%   2874
  90%   2909
  95%   2948
  98%   2992
  99%   3014
 100%   4679 (longest request)

# 整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间,其中50%的用户响应时间小于2397 毫秒,66% 的用户响应时间小于2842 毫秒,最大的响应时间小于4679 毫秒

测试结果显示:nginx吞吐率为:Requests per second: 384.18 [#/sec] (mean)。

通过上面的数据可分析出服务器响应情况,并发处理能力,尤其是Requests per second参数,它确定了服务器的秒并发能力。

性能指标Requests per second吞吐率越高,服务器性能越好。

查看服务器相关数据

查看Web服务器(Nginx Apache)的并发请求数及其TCP连接状态:
   netstat -n |awk '/^tcp/ {++S[$NF]}END{for(a in S)print a,S[a]}'

或者

  netstat -n|grep  ^tcp|awk '{print $NF}'|sort -nr|uniq -c

或者:

netstat -n |awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"t",state[key]}'

返回结果一般如下:
LAST_ACK 5 (正在等待处理的请求数)
ESTABLISHED 1597 (正常数据传输状态) FIN_WAIT1 51 FIN_WAIT2 504
TIME_WAIT 1057 (处理完毕,等待超时结束的请求数)

其他参数说明:
CLOSED:无连接是活动的或正在进行
LISTEN:服务器在等待进入呼叫
SYN_RECV:一个连接请求已经到达,等待确认
SYN_SENT:应用已经开始,打开一个连接
ESTABLISHED:正常数据传输状态
FIN_WAIT1:应用说它已经完成
FIN_WAIT2:另一边已同意释放
ITMED_WAIT:等待所有分组死掉
CLOSING:两边同时尝试关闭
TIME_WAIT:另一边已初始化一个释放
LAST_ACK:等待所有分组死掉 LAST_ACK 5 (正在等待处理的请求数)
ESTABLISHED 1597 (正常数据传输状态) FIN_WAIT1 51 FIN_WAIT2 504
TIME_WAIT 1057 (处理完毕,等待超时结束的请求数)

查看Nginx运行进程数
ps -ef |grep nginx|wc -l
返回的数字就是nginx的运行进程数,如果是apache则执行
 ps -ef |grep httpd|wc -l
查看Web服务器进程连接数:
netstat -antp|grep 80|grep ESTABLISH -c
查看MySQL进程连接数:
ps -axef|grep mysqld -c