nginx、php-fpm默认配置与性能–TCP socket还是unix domain socke
nginx、php-fpm默认配置与性能–TCP socket还是unix domain socke
seared2008 发表于3年前
nginx、php-fpm默认配置与性能–TCP socket还是unix domain socke
  • 发表于 3年前
  • 阅读 24
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 技术升级10大核心产品年终让利>>>   

前几天看到一篇博客,提到php所在服务器在大并发情况下,频繁创建TCP短连接,而其所在服务器的2MSL时间过长,导致没有端口可用,系统无法创建TCP socket,而大量报错。博主在后面给的解决方案是减少2MSL的时间,尽快清除TIME_WAIT状态的TCP连接,回收端口。同时,文章结尾写了不用长连接的理由,但这真的是最好的解决办法吗?有其他办法可以更好的做法吗?

类似经历
之所以多这篇文章兴趣这么高,是因为在前段时间,末学也经历了一件类似的优化历程,先简短的描述下我们的服务器架构。如图

一款webgame 粗略架构图

想必看到这幅架构图的同学,都比较熟悉吧,也比较简单。“最前面”的nginx 反代负责与玩家的http请求通讯,这里是长连接。在其与后端游戏大区通讯时,使用了短连接,也就是意味着,每处理用户的一个http请求,都要重新与后端的nginx建立一次TCP(http)请求,后端nginx处理完之后就关闭。后端的nginx与php在同一台服务器上,通讯配置如下:

01 //NGINX 反代
02 upstream server1 {
03     server  10.10.10.1   max_fails=2  fail_timeout=30s;  #app1
04     server  10.10.10.2   max_fails=2  fail_timeout=30s;  #app2
05 }
06
07 // 后端NGINX
08 // Nginx 默认配置 http://trac.nginx.org/nginx/browser/nginx/trunk/conf/nginx.conf
09 location ~ \.php$ {
10     root           html;
11     fastcgi_pass   127.0.0.1:9000;
12     fastcgi_index  index.php;
13     fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
14     include        fastcgi_params;
15 }
16
17 //PHP-FPM
18 //PHP-FPM 默认配置 https://github.com/php/php-src/blob/master/sapi/fpm/php-fpm.conf.in
19 ; The address on which to accept FastCGI requests.
20 ; Valid syntaxes are:
21 ;   'ip.add.re.ss:port'    - to listen on a TCP socket to a specific address on a specific port;
22 ;   'port'                 - to listen on a TCP socket to all addresses on a specific port;
23 ;   '/path/to/unix/socket' - to listen on a unix socket.
24 ; Note: This value is mandatory.
25 listen = 127.0.0.1:9000

在这个架构图中,反代承担这承上启下的作用,前面是用户,后面是web app服务器,长连接用户,短连接后端。若用户数在1W人,1W人与反代的连接,在反代服务器上都用80端口。但这1W人的每一个请求,反代都要重新使用服务器的端口与后端nginx的80创建tcp socket,来处理请求。若2MSL时间为1分钟以上,同时,玩家两次请求间隔很短,想我们游戏的服务器,两次请求间隔大约5秒(甚至2-3秒)。那么反代的端口,5秒用1W个,10秒2W,15秒3W,20秒4W,25秒5W,30秒6W!!!,前面已经用掉的端口还没被回收掉。那么将会有很多的用户请求被nginx反代接收之后,因没有端口资源而无法与后端nginx创建tcp连接。。。以游戏的其中一个大区为例:

关于这个问题,末学在新浪微博上请教过其他大牛,其中tengine负责人淘叔度前辈以及@120斤的大青蛙前辈告诉我,nginx将在1.1.4版本开始支持ngx_http_upstream_keepalive,3月1号左右,是1.1.16 dev版本,我们的运维团队稍微由于几天,之后在部分小区的服务器上适用了1.1.16,效果不错,Nginx反代上与目标服务器的80端口的TCP连接中处于ESTABLISHED状态的非常多,TIME_WAIT的几乎没有,很稳定。我们几乎计划为了这个性能的提升,决定用dev版了。接着nginx1.2Stable version也出来了,那么也就用这个版本了。至于反代上nginx与后端app server建立TCP连接个数,也就是端口数(满载情况下,维持ESTABLISHED状态)的为nginx worker_processes * ((upstream1 server * keepalive参数数量) + (upstream2 server * keepalive参数数量) + …),并不多。

如上,端口占用数少了,那么还有其他有点吗?先看一副 socket创建,监听、数据接收发送、关闭与客户端连接的socket流程图:

如上图,nginx反代跟后端nginx的形式跟php-fpm与mysqld socket的模型一样的。
nginx反代跟php-fpm 相对来说,就是客户端,这种做法,他们的每个新socket 请求的发起,都会跟着左边的流程走一遍,一遍又一遍。。。。每次的socket创建,端口等资源申请,与服务端的三次握手,关闭时的四次握手,端口的回收。。。。
改用长连接之后,如下图:

只有php-fpm(或者nginx反代)的子进程分别与mysqld创建1次TCP连接,之后都是send、recv数据的事情了,端口占用也是为数不多的几个(每个fpm子进程将与mysqld维持一个TCP长连接)。

同样,后端服务器的nginx与php-fpm的通讯也是如此,只是请求两没有反代那么大。区别就是IP地址是回环地址127.0.0.1。
既然是回环地址,那么两个服务都是在同一台机器上跑的,既然是同一台机器,为何不用进程间通讯的socket–unix domain socket呢?
socket是神马?摘抄一段描述:

Socket 可以被定义描述为两个应用通信通道的端点。一个 Socket 端点可以用 Socket 地址来描述, Socket 地址结构由 IP 地址,端口和使用协议组成( TCP or UDP )。http协议可以通过socket实现,socket在传输层上实现。从这个角度来说,socket介于应用层和传输层之间。但是socket作为一种进程通信机制,操作系统分配唯一一个socket号,是依赖于通信协议的,但是这个通信协议不仅仅是 tcp或udp,也可以是其它协议。

在同一台服务器上,用tcp socket与unix domain socket有什么区别?
如图所示,对于进程间通讯的两个程序,unix domain socket的流程不会走到TCP 那层,直接以文件形式,以stream socket通讯。如果是TCP socket,则需要走到IP层。

对于非同一台服务器上,TCP socket走的就更多了。

至于localhost\127.0.0.1以及网络IP他们之间的区别,无意中找到一篇博客写的是以mysql作为验证,来说明localhost不走TCP/IP层,跟127.0.0.1不一样。末学认为他理解错了。他的理由如下

(以下截图均在linux上,windows的没有unix domain socket)
mysql连接本机时,不加-h参数:

mysql连接本机时,加-h参数且值是localhost:

mysql连接本机时,加-h参数且值是127.0.0.1:

那位同学从mysql工具的使用方法、与结果的区别,来理解推导localhost与127.0.0.1的区别,这从方向上就存在问题,我更相信,这是mysql这个程序自己的行为,遇到-h参数没加,或者-h参数的值不是IP形式,且my.cnf里指定mysql的socket路径时,则直接使用unix domain socket来连接服务器,当然,这也是我的猜测,没有去验证,大家听听就好,别相信。

鉴于末学对以上的理解,将服务器的架构配置变更如下

01 //NGinx 反代配置
02 upstream server1 {
03         keepalive 10 single;
04         //参见nginx官方wiki,记得看E文版,中文版的还没更新 http://wiki.nginx.org/NginxHttpUpstreamModule
05         server 10.10.8.97  max_fails=2 fail_timeout=30s;  #app1
06         server 10.10.8.99  max_fails=2 fail_timeout=30s;  #app2
07         server 10.10.8.85  max_fails=2 fail_timeout=30s;  #app3
08 }
09
10 //NGINX配置
11 //获取PHP扩展名的规则,适用于
12 location ~ ^([^.]+\.php)($|/.*) {
13     fastcgi_pass unix:/var/run/php5-fpm.sock;
14     fastcgi_index index.php;
15     include fastcgi_params;
16 }
17
18 //php-fpm配置
19 ; Note: This value is mandatory.
20 listen = /var/run/php5-fpm.sock //与nginx 的fastcgi_pass的路径一致即可,目录要有相应读写权限

至此,优化还为完毕,若php-fpm与mysql使用mysql_pconnect的话,那么php-fpm的子进程生成模式最好用static模式,若为dynamic模式,可能会出现mysql连接数被占满的情况,这也跟mysql服务的连接超时时间有关,适当调整也容易避免。
不过,我们目前还没用mysql_pconnect,主要原因是我们的代码中,有些事务处理开启之后,对于代码的失败处理,忘记写回滚语句,在短连接的情况下,这个连接的销毁,哪怕客户端没提交ROLLBACK或者COMMIT指令,mysql会自动回滚之前的事务。但使用长连接之后,不同请求会使用同一个MYSQL连接句柄,每个事务开启都会禁用MYSQL的自动提交,即SET AUTOCOMMIT=0语句,这语句会提交之前的事务。对于我们代码忘记写回滚,而直接返回结果的情况下,这是会出大问题的,也是我们目前唯一没有使用MYSQL_pconnect的原因。(计划近期找到没有写回滚语句的代码,修复,继续使用mysql_pconnect)

其实还有,我们php-fpm使用了APC来缓存php file,以及 变量数据等,这些也是有优化的地方(如果有时间的话,则待续)。

回过头来再理解下文章开头那位同学给的解决办法,我仍不能从他给的理由中,理解长连接的缺点,哪怕是解决了TIME_WAIT的问题,但每次创建TCP socket ,连接到服务器时三次握手,关闭TCP socket时的四次握手 这些也是开销。当然,缩短2MSL的时间,也是更好利用服务器资源的一个好方法。

最后,我们调整优化的服务器架构图如下:

好像有点偏离这篇文章的标题了,其实我更想说我不能理解为啥nginx跟php-fpm给的默认配置中,都是TCP socket通讯的,为啥不默认给unix domain socket的默认配置呢?如果说为了方便非同一台服务器时的情况,但给的默认IP也是回环地址呀。
而且,nginx给默认配置中,对于uri请求中的php文件的处理,匹配规则还是老的,之前发生因为NGINX与PHP的配置而导致的安全问题,虽然不是nginx的错,但nginx也可给出更严谨的范例,但仍没有。

值得欣慰的是,在UBUNTU 12.4中,nginx的默认配置有了很大的改进,不管是匹配uri的规则,还是nginx与php-fpm的交互方式:

01 #location ~ \.php$ {
02 #       fastcgi_split_path_info ^(.+\.php)(/.+)$;    //赞1
03 #       # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
04 #
05 #       # With php5-cgi alone:
06 #       fastcgi_pass 127.0.0.1:9000;    //赞3
07 #       # With php5-fpm:
08 #       fastcgi_pass unix:/var/run/php5-fpm.sock;    //赞3
09 #       fastcgi_index index.php;
10 #       include fastcgi_params;
11 #}

PS:末学只是个web程序员,这些只是末学学习研究如上知识的总结,理解上难免有错,各位请海涵。


共有 人打赏支持
粉丝 5
博文 33
码字总数 7080
×
seared2008
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: