LNMP資源分配和并發(fā)配置的方法是什么

Linux+Nginx+Mysql/MariaDB+Perl/PHP/Python一組常用來搭建動態(tài)網站或者服務器的開源軟件，本身都是各自獨立的程序，但是因為常被放在一起使用，擁有了越來越高的兼容度，共同組成了一個強大的Web應用程序平臺。

LNMP中的N是nginx充當Web Server

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

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

那么php與nginx的常規(guī)協(xié)作方式是如何的呢？需要我們明確幾個概念

cgi

通用網關接口，是HTTP協(xié)議中描述的，Web Server與后端處理程序進程間通信的協(xié)議

php-cgi

php實現了cgi協(xié)議，使得web server與php共同完成一個動態(tài)網頁的請求響應

fastcgi

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

php-fpm

實現了fastcgi協(xié)議，是php-cgi的進程管理器，解決高并發(fā)網站的性能問題。

在最終回答LNMP的并發(fā)考慮與資源分配還需要明確的幾個概念

并發(fā)

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

性能

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

資源分配

php-fpm進程數

按照上面的描述，并發(fā)為5000每秒，每個請求完成大約200ms（具體頁面要具體分析，這里只是一個理想值），如果只有5臺PHP應用程序服務器，那么每臺機器平均為并發(fā)1000每秒，如果是使用nginx+php-fpm的架構，php-fpm的php-cgi進程管理器的配置應該如何呢？我計算的結果為（具體的配置項說明在后文）： pm=static pm.max_children=100 上面的100是如何得來的，由于機器平均并發(fā)為1000每秒，每個動態(tài)請求的處理時間為100ms，也就是說1個php-fpm的worker處理進程在1秒內可以處理10個請求，100個php-fpm的worker處理進程，就可以處理1000個請求。 當然需要結合服務器硬件資源來進行配置，如果配置不當，很容易在請求高峰期或者流量猛增導致服務器宕機。

網絡帶寬

網絡帶寬也會是一個重要的因素，如果你的服務處理很強，但是用戶的請求和響應不能及時到達也是白忙活，這個參數如何計算呢？ 并發(fā)5000每秒，每個請求的輸出為20K，則5000x20K=100000K=100M 這就要求你的公網負載均衡器外網帶寬至少要達到100M

內存

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

CPU

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

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相關的配置項有

進程管理器以控制子進程的數量，可能的值有
static 一個固定的值，由pm.max_children指定
dynamic 動態(tài)的（工作方式和Apache的prefork模式一致），但是保持至少一個，由
pm.max_children 在同一時間最大的進程數
pm.start_servers php-fpm啟動時開啟的等待請求到來的進程數
pm.min_spare_servers 在空閑狀態(tài)下，運行的最小進程數，如果小于此值，會創(chuàng)建新的進程
pm.max_spare_servers 在空閑狀態(tài)下，運行的最大進程數，如果大于此值，會kill部分進程
ondemand 啟動時不會創(chuàng)建進程，當請求達到時創(chuàng)建子進程處理請求
pm.max_children 在同一時間最大的進程數
pm.process_idle_timeout 空閑多少秒之后進程會被killpm = dynamic

   pm.max_children

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

   pm.start_servers

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

   pm.min_spare_servers

在空閑狀態(tài)下，運行的最小進程數，如果小于此值，會創(chuàng)建新的進程
pm.min_spare_servers = 60

   pm.max_spare_servers

在空閑狀態(tài)下，運行的最大進程數，如果大于此值，會kill部分進程
pm.max_spare_servers = 120

   pm.process_idle_timeout

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

   pm.max_requests

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

   pm.status_path

注冊的URI，以展示php-fpm狀態(tài)的統(tǒng)計信息
pm.status_path = /status
其中統(tǒng)計頁面信息有：
pool 進程池名稱
process manager 進程管理器名稱（static, dynamic or ondemand）
start time php-fpm啟動時間
start since php-fpm啟動的總秒數
accepted conn 當前進程池接收的請求數
listen queue 等待隊列的請求數
max listen queue 自啟動以來等待隊列中最大的請求數
listen queue len 等待連接socket隊列大小
idle processes 當前空閑的進程數
active processes 活動的進程數
total processes 總共的進程數（idle+active）
max active processes 自啟動以來活動的進程數最大值
max children reached 達到最大進程數的次數

   ping.path

ping url，可以用來測試php-fpm是否存活并可以響應
ping.path = /ping

   ping.response

ping url的響應正文
ping.response = pong