LNMP就是linux+nginx+mysql+php環境了,這個是linux中常用的一個WEB服務器搭配,下文來介紹lnmp的并發考慮、資源分配(php-fpm進程管理器的核心配置)了,有興趣的可參考一下.

下面總結在最近招聘中常問的一個問題:

PHPer當被問到你的程序性能如何？程序的并發可以達到多少？程序的瓶頸在哪兒？為了滿足業務需求應該購買多少臺服務器？負載均衡中php應用服務器需要多少臺？

可能這些問題在面試中會設置一個應用的場景及一些前提條件,讓面試的人去設計,并提出看法建議,能夠回答得很好的人還是比較少的.

今天我們來談談LNMP的并發考慮和資源分配,首先弄清楚幾個概念.

LNMP中的N是nginx充當Web Server

內容的分發者,會在文件系統找到相應的文件,就返回給瀏覽器,如:nginx,如果是靜態的文件,就可以直接返回,但是如果是index.php需要解析并執行的腳本文件時,Web Server就無力了,需要將請求轉發給相應的腳本語言的解析器來解釋并執行,最終將程序的執行結果,返回給Web Server,再返回給瀏覽器.

LNMP中的P是php充當后端的邏輯處理程序

那么php與nginx的常規協作方式是如何的呢?需要我們明確幾個概念

cgi:通用網關接口,是HTTP協議中描述的,Web Server與后端處理程序進程間通信的協議.

php-cgi:php實現了cgi協議,使得web server與php共同完成一個動態網頁的請求響應

fastcgi

是為了解決cgi性能問題，而規范的另外一種協議,為什么說解決cgi性能問題,因為在面對各大中型網站的業務需求中,cgi程序表現得越來越無力,因為cgi程序在每次接收到請求時都需要啟動新的進程,并初始化環境,然后執行程序,具體的協議內容,在此不引述.

php-fpm

實現了fastcgi協議,是php-cgi的進程管理器,解決高并發網站的性能問題,在最終回答LNMP的并發考慮與資源分配還需要明確的幾個概念.

并發:一般由單位內完成的請求數來衡量,如,每秒事務數(TPS),每秒HTTP請求數(HPS),每秒查詢數(QPS),通常情況下,我們說PHP的并發,都是指一秒內PHP完成的動態請求的次數。如某網站高峰期的動態請求并發為5000每秒,這個數字不算太高,但也不低,一般日活躍用戶數在1000萬-5000萬的網站應用才能達到這個級別.

性能:一般是指應用程序的處理速度，如果php的應用程序，打開一個頁面（執行一個腳本程序）通常需要在50-100ms完成，這對程序的性能要求還是比較高的。但是這還僅僅只是程序處理，php處理完成之后，還要交給web server，web server再將數據返回瀏覽器，這中間會有一個網絡延遲，通常網絡正常的情況下，需要大約100ms，最終一個動態網頁的請求大約200ms（理想的情況下）可以到達用戶瀏覽器端（僅僅是一個html結構）。

資源分配

1）php-fpm進程數

按照上面的描述，并發為5000每秒，每個請求完成大約200ms（具體頁面要具體分析，這里只是一個理想值），如果只有5臺PHP應用程序服務器，那么每臺機器平均為并發1000每秒，如果是使用nginx+php-fpm的架構，php-fpm的php-cgi進程管理器的配置應該如何呢？我計算的結果為（具體的配置項說明在后文）：

pm=static

pm.max_children=100

上面的100是如何得來的，由于機器平均并發為1000每秒，每個動態請求的處理時間為100ms，也就是說1個php-fpm的worker處理進程在1秒內可以處理10個請求，100個php-fpm的worker處理進程，就可以處理1000個請求。

當然需要結合服務器硬件資源來進行配置，如果配置不當，很容易在請求高峰期或者流量猛增導致服務器宕機。

2）網絡帶寬

網絡帶寬也會是一個重要的因素，如果你的服務處理很強，但是用戶的請求和響應不能及時到達也是白忙活，這個參數如何計算呢？

并發5000每秒，每個請求的輸出為20K，則5000x20K=100000K=100M,這就要求你的公網負載均衡器外網帶寬至少要達到100M

3）內存

上述中100個php-fpm的worker處理進程，理論上如果服務器只運行php-fpm，那么我們可以將服務器內存的一半分配給php-fpm，通常情況下，我們可以認為一個php-fpm的worker處理進程占用內存20M，那么100x20M=2G，也就是說明服務器的內存大約為4G

4）CPU

由于php-fpm是一個多進程的模型應用，CPU進程調度消耗也是很大的，并且PHP應用程序有問題也會導致CPU占用率高，這就沒有量化的指標，需要具體情況具體分析了。但是有一個小建議，可以部署一個crontab每隔一分鐘檢測cpu占用率超過多少就kill掉相應的php-fpm的worker處理進程。

5）nginx與php-fpm使用unix域套接字代替tcp socke進行通信,這個配置挺關鍵的,純echo的ab測試,采用unix域套接字每秒請求數提升10%-20%,即nginx中配置:

fastcgi_pass unix:/data/server/var/php/php-fpm.sock;

php-fpm.conf中配置:

listen = /data/server/var/php/php-fpm.sock

最后遇到很多同學對php-fpm的進程管理器的核心配置不太了解,下面是我翻譯的配置說明.

首先php-fpm相關的配置項有:

1）pm,進程管理器以控制子進程的數量,可能的值有.

static 一個固定的值，由pm.max_children指定

dynamic 動態的(工作方式和Apache的prefork模式一致),但是保持至少一個,由

pm.max_children 在同一時間最大的進程數.

pm.start_servers php-fpm啟動時開啟的等待請求到來的進程數

pm.min_spare_servers 在空閑狀態下,運行的最小進程數,如果小于此值,會創建新的進程.

pm.max_spare_servers 在空閑狀態下,運行的最大進程數,如果大于此值,會kill部分進程.

ondemand 啟動時不會創建進程，當請求達到時創建子進程處理請求

pm.max_children 在同一時間最大的進程數

pm.process_idle_timeout 空閑多少秒之后進程會被kill

pm = dynamic

2）pm.max_children

在同一時間最大的進程數

pm.max_children = 120

3）pm.start_servers

php-fpm啟動時開啟的等待請求到來的進程數，默認值為：min_spare_servers + (max_spare_servers - min_spare_servers) / 2

pm.start_servers = 80

4）pm.min_spare_servers

在空閑狀態下，運行的最小進程數，如果小于此值，會創建新的進程

pm.min_spare_servers = 60

5）pm.max_spare_servers

在空閑狀態下，運行的最大進程數，如果大于此值，會kill部分進程

pm.max_spare_servers = 120

6）pm.process_idle_timeout

空閑多少秒之后進程會被kill，默認為10s

pm.process_idle_timeout = 10s

7）pm.max_requests

每個進程處理多少個請求之后自動終止,可以有效防止內存溢出,如果為0則不會自動終止,默認為0

pm.max_requests = 5000

8）pm.status_path

注冊的URI，以展示php-fpm狀態的統計信息

pm.status_path = /status

其中統計頁面信息有:

1. pool 進程池名稱 
2. process manager 進程管理器名稱（static, dynamic or ondemand） 
3. start time php-fpm啟動時間 
4. start since php-fpm啟動的總秒數 
5. accepted conn 當前進程池接收的請求數 
6. listen queue 等待隊列的請求數 
7. max listen queue 自啟動以來等待隊列中最大的請求數 
8. listen queue len 等待連接socket隊列大小 
9. idle processes 當前空閑的進程數  --Vevb.com 
10. active processes 活動的進程數 
11. total processes 總共的進程數（idle+active） 
12. max active processes 自啟動以來活動的進程數最大值 
13. max children reached 達到最大進程數的次數 

9）ping.path

ping url,可以用來測試php-fpm是否存活并可以響應

ping.path = /ping

10）ping.response

ping url的響應正文

ping.response = pong