原文地址：https://www.cnxct.com/default-configuration-and-performance-of-nginx-phpfpm-and-tcp-socket-or-unix-domain-socket/
前幾天看到一篇博客，提到php所在服務器在大並發情況下，頻繁創建TCP短連接，而其所在服務器的2MSL時間過長，導致沒有端口可用，系統無法創建TCP socket，而大量報錯。博主在后面給的解決方案是減少2MSL的時間，盡快清除TIME_WAIT狀態的TCP連接，回收端口。同時，文章結尾寫了不用長連接的理由，但這真的是最好的解決辦法嗎？有其他辦法可以更好的做法嗎？
類似經歷
之所以多這篇文章興趣這么高，是因為在前段時間，末學也經歷了一件類似的優化歷程，先簡短的描述下我們的服務器架構。如圖
一款webgame 粗略架構圖
想必看到這幅架構圖的同學，都比較熟悉吧，也比較簡單。“最前面”的nginx 反代負責與玩家的http請求通訊，這里是長連接。在其與后端游戲大區通訊時，使用了短連接，也就是意味着，每處理用戶的一個http請求，都要重新與后端的nginx建立一次TCP(http)請求，后端nginx處理完之后就關閉。后端的nginx與php在同一台服務器上，通訊配置如下：
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
//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來連接服務器，當然，這也是我的猜測，沒有去驗證，大家聽聽就好，別相信。
鑒於末學對以上的理解，將服務器的架構配置變更如下
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
|
//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的交互方式：
|
01
02
03
04
05
06
07
08
09
10
11
|
#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;
#}
|