nginx、php-fpm默认配置与性能–TCP socket还是unix domain socket

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

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

一款webgame 粗略架构图

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

//NGINX 反代
upstream server1 {
    server  10.10.10.1   max_fails=2  fail_timeout=30s;  #app1
    server  10.10.10.2   max_fails=2  fail_timeout=30s;  #app2
}

// 后端NGINX 
// Nginx 默认配置 http://trac.nginx.org/nginx/browser/nginx/trunk/conf/nginx.conf
location ~ \.php$ {
    root           html;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    include        fastcgi_params;
}

//PHP-FPM
//PHP-FPM 默认配置 https://github.com/php/php-src/blob/master/sapi/fpm/php-fpm.conf.in
; The address on which to accept FastCGI requests.
; Valid syntaxes are:
;   'ip.add.re.ss:port'    - to listen on a TCP socket to a specific address on a specific port;
;   'port'                 - to listen on a TCP socket to all addresses on a specific port;
;   '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
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来连接服务器,当然,这也是我的猜测,没有去验证,大家听听就好,别相信。

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

//NGinx 反代配置
upstream server1 {
        keepalive 10 single; 
        //参见nginx官方wiki,记得看E文版,中文版的还没更新 http://wiki.nginx.org/NginxHttpUpstreamModule
        server 10.10.8.97  max_fails=2 fail_timeout=30s;  #app1
        server 10.10.8.99  max_fails=2 fail_timeout=30s;  #app2
        server 10.10.8.85  max_fails=2 fail_timeout=30s;  #app3
}

//NGINX配置 
//获取PHP扩展名的规则,适用于
location ~ ^([^.]+\.php)($|/.*) {
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
}

//php-fpm配置
; Note: This value is mandatory.
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的交互方式:

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

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

知识共享许可协议CFC4N的博客CFC4N 创作,采用 知识共享 署名-非商业性使用-相同方式共享(3.0未本地化版本)许可协议进行许可。基于https://www.cnxct.com上的作品创作。转载请注明转自:nginx、php-fpm默认配置与性能–TCP socket还是unix domain socket

22 thoughts on “nginx、php-fpm默认配置与性能–TCP socket还是unix domain socket

  1. 好文章。
    不过本文更多的是关于Nginx对后端Server长连接的支持了。
    关于最前面提到的淘宝文章,短连接的适用场景,原因是要确定各自业务的主要矛盾,比如对于Apache/nginx面对终端用户,虽然keepalive可以使得一个用户的页面访问加快,但减少了并发能力,对出小活动这种尖峰访问不利;对后端server的长连接,也容易出现阻塞判定等问题……所以他们的场景可能弊大于利。

  2. 讲得很好!对于nginx和php-fpm的通信,我确认两件事情:1、当选择unix domain socket的时候,fastcgi_keep_conn这个设置是否就没意义了?2、unix domain socket和127.0.0.1:port fastcgi_keep_conn来比较的话,性能是否差不多?

    • 对IT运营进行独立的评估,可以帮助确定具体的漏洞或弱点,并且开发出维护信息安全宣教的综合解决方案。http://t.cn/zHkCzKl

  3. 我有一个疑问,如果nginx后跑了两台php服务器,是不是不能用unix socket了

    • server与client通讯时,复用server的端口。但当php-fpm跟后端mysql通讯时,php-fpm就变成client了,它再跟mysql通讯时,就必须新占用一个端口了。

  4. 文章提到两个部分,第一部分是代理nginx的端口解决问题,利用高版本nginx的ngx_http_upstream_keepalive解决端口不够问题,第二部分是nginx的web应用和php-fpm的交互带来的端口不够问题。实际上,1、做负载,选择F5,LVS或是A10都要比Nginx做负载来的可靠,2、如果选择nginx做代理,配置长连接确实有必要。3、利用unix域socket,没有TCPsocket来的安全稳定,同时此处的瓶颈怕不是端口问题而是脚本处理时长了,所以第二部分没有太大必要

    • 1,嗯,正如您所说,大企业的话,大手笔,就用F5之类高大上的产品,小企业用nginx的,也只能这样了。
      3,只要想说单机的进城之间数据通讯,用TCP形式,浪费TCP建立时的各种握手步骤,unix domain socket形式,会省去这些细节。不过,从我的测试上来看,确实没有TCP的稳定。并发小时,看不出来区别的。

  5. 作者的文章分析的很详细,赞一个!有助于帮助其他人了解这种使用模式。不过个别的地方有错别字,要是能改改,就更完善了。另外图片默认打开很小,也有点影响阅读体验:)

Comments are closed.