phpfpm原理

Ⅰ cgi、fastcgi、php-cgi、php-fpm異同

1. cgi

    - 通用網關介面，就是外部應用程序（cgi程序）與web伺服器之間的介面標准。

    - nginx是內容分發者，如果是請求index.php，根據配置文件內容得知不是靜態文件，就會去找對應的cgi程序進行解析

    - cgi就是規定要傳那些數據，以什麼格式傳遞給後方進行處理的協議

    - cgi工作模式，一個請求發送過來，啟動cgi解釋器（創建進程）-> 邏輯處理 -> 退出 （fork and exec 模式） 每次都需要重新創建進程，載入配置，浪費系統資源

2. fastcgi

    - 快速通用網關介面，常駐型的cgi，不用每次都fork進程，其會使cgi解解釋器進程常駐內存，所以性能較高

    - master-worker模型，伺服器啟動時載入fastcgi進程管理器

    - fastcgi會進行自身初始化，初始化時會創建多個進程

    - 請求到達web伺服器後，fastcgi進程管理器會選擇並通過socket連接到一個cgi解釋器

3. php-cgi

    - php自帶的cgi管理器

    - php-cgi的缺點，不能平滑重啟，需要重啟php-cgi才能使php.ini生效

4. php-fpm

    - php-fpm是php的一種fastcgi的實現，管理php的fastcgi進程池

    - 能夠調度php-cgi程序

    - 能夠實現平滑重啟

    - php-fpm創建一個master進程，然後創建進程池，監聽socket，fork出多個子進程，子進程各自accept請求，php-fpm的子進程同時只能響應一個請求，處理完一個請求才可以accept下一個請求，多進程，同步阻塞模型

    - master和worker進程之間不直接進行通信，master通過共享內存獲取worker進程信息，master進程發送信號通知worker進程

    - php-fpm可以同時監聽多個埠，每個埠對應一個worker pool

    - worker是cgi程序，php-fpm是fastcgi協議的php是實現

Ⅱ 關於FastCGI、php-cgi、php-fpm的區別是什麼，各自有什麼用途，以及相互間的關系是什麼

fastcgi是一個通用網關介面，用於web伺服器(iis, apache)和應用程序通信。

php-cgi是php平台的cgi程序
以上兩個結合，可以使php整合在web服務中
php-fpm是一個獨立的php-fcgi管理軟體，它要整合進web服務中，需要使用代理模式
一般與nginx搭配。也可以與apache搭配
php-fpm一般不直接作為服務容器提供外網訪問，而是通過常用web容器作代理

php作為伺服器端的解析程序，運行模式分很多種，fastcgi, mod_php, proxy(代理)等。
與iis搭配時一般採用fast-cgi模式，iis自帶fast-cgi引擎，配置好php參數即可
與apache搭配，在windows平台下，一般也是fast-cgi模式，在linux系統中一般是mod_php模式，把php作為一個子模塊載入
也可以配置php-fpm 然後在apache中配置代理模式
與nginx搭配，一般就是用php-fpm+代理模式了

Ⅲ 了解PHP-FPM

在伺服器上，當我們查看php進程時，全都是php-fpm進程，大家都知道這個就是php的運行環境，那麼，它到底是個什麼東西呢？

PHP-FPM，就是PHP的FastCGI管理器，用於替換PHP FastCGI的大部分附加功能，在PHP5.3.3後已經成為了PHP的標配。

有小夥伴要問了，FastCGI又是什麼鬼？CGI程序又叫做「通用網關介面」，就是讓Web伺服器和你的應用程序進行交互的一個介面。就像nginx中需要配置的fastcgi_pass，一般我們會使用127.0.0.1:9000或者unix:/tmp/php-cgi.sock來配置這個參數。它的意思就是告訴nginx，過來的請求使用tcp:9000埠的監聽程序來處理或者使用unix/socket來處理。它們都是指向的PHP運行程序。

再說得通俗一點，我們運行php腳本用的是

php-fpm就相當於是這個php命令。nginx通過fastcgi_pass來運行php $nginx_root(nginx配置文件中網站根目錄root配置)下的index.php。所以，如果你用的是python或者其他什麼語言，都可以用它們的cgi程序來讓nginx調用。

FastCGI和CGI又有什麼不同呢？FastCGI是啟動一個socket介面，伺服器應用不需要自己去運行php，只需要向這個socket介面提交請求就可以了。

php-fpm在編譯php時需要添加--enable-fpm。一些通用的集成安裝包如lnmp、phpStudy等都會默認編譯並使用php-fpm，畢竟是標配。

上文中說過nginx可以使用127.0.0.1:9000和unix:/tmp/php-cgi.sock這兩種方式來調用php-fpm。它們有什麼區別呢？

前者，一般帶9000埠號的，是tcp形式的調用。也就是php-fpm啟動了一個監聽進程對9000埠進行監聽。它會調起一個tcp/ip服務，nginx在調用的時候會走一次tcp請求流程，也就是3次握手4次揮手，會走到網路七層中的第四層傳輸層。相對來說這種方式性能會稍差一點，啟動php-fpm後使用nestat查看埠中會出現9000埠的佔用。

後者，使用的是unix套接字socket服務，通過sock文件來交換信息，性能相對好一些，因為它沒有tcp連接過程，也不會有9000埠的佔用。

對於高負載大訪問量的網站還是推薦使用unix方式，對於普通小網站來說，無所謂使用哪個都可以，tcp方式反而更容易配置和理解，也是php-fpm.conf中默認的監聽方式。

php-fpm.conf配置中的listen屬性用來配置監聽，這里的配置要和nginx中的一致，使用tcp的就監聽127.0.0.1:9000，使用unix的就設置成/tmp/php-cgi-56.sock。

以下內容摘自官方文檔：

===========

各自媒體平台均可搜索【硬核項目經理】

Ⅳ PHP FPM源代碼反芻品味之四：事件處理

FPM master 進程啟動後，會進入函數fpm_event_loop,無限循環.
處理事件.

master 進程所做的的事，總的來說就是兩類：

簡稱timer事件,需按時運行，主要有3個:

簡稱fd事件,需從文件句柄(file descriptor)讀取到指令後，依指令運行．
重復一下，unix 下一切IO, 皆文件，socket ,socketpair,pipe 都返迴文件句柄(fd) 用於通信．
主要的fd有:

對於timer事件，多個事件在事件軸上是依次排列的，只需反復檢查，到時運行．
對於fd事件，需監聽多個fd，需用到我們第二篇講的IO多路復用技術．

如果滿足事件條件，則處理事件內容．

FPM設計上，兩類事件使用同一個結構，並且事件觸發條件和事件處理邏輯放到同一個事件對象里(C語言對象就是結構體)．
舉個例子， 打鈴下課，打鈴是觸發條件，下課是事件內容，兩個同時放到一個事件對象 ，這是一個很好的設計．

fd值: -1
flags值:FPM_EV_PERSIST
which值: FPM_EV_TIMEOUT

fd值: 獲取觸發指令的文件fd
flags值: FPM_EV_EDGE(fd事件底層的邊緣觸發標志,需系統支持)
which值: FPM_EV_READ

兩類事件分別放在兩個事件隊列
static struct fpm_event_queue_s *fpm_event_queue_timer = NULL;
static struct fpm_event_queue_s *fpm_event_queue_fd = NULL;

事件隊列的結構很常見，雙向隊列：
typedef struct fpm_event_queue_s {
struct fpm_event_queue_s *prev;
struct fpm_event_queue_s *next;
struct fpm_event_s *ev;
} fpm_event_queue;

4移除事件 (fpm_event_del -> fpm_event_queue_del)
簡單的出列操作：
static int fpm_event_queue_del(struct fpm_event_queue_s **queue, struct fpm_event_s *ev)
對於fd事件,需在底層事件輪詢機制里移除（如：epoll）

5,運行事件回調函數：

6, 底層事件輪詢模塊結構

不同的操作系統，支持不同的IO事件機制，linux 支持epoll,
windows支持select, freebsd 支持kqueue,這個結構統一操作介面
在函數fpm_event_init_main里 調用mole->init初始化
fpm 里對應的配置

master進程在fpm_event_loop函數里無限循環，處理定時任務和fd事件.
期間會在mole->wait阻塞片刻，對於epoll機制，就是epoll_wait．

Ⅳ nginx與php-fpm的簡單的關系流程圖

流程：

1，首先Browser通過Http協議發送一個請求到Nginx伺服器

2，Nginx服務判斷是否為靜態資源是的話直接放回，否則載入nginx.conf配置文件里的fastcgi模塊。
3，Nginx通過fastcgi_pass （默認是127.0.0.0:9000）把對應的請求按照fastcgi協議轉發到PHP-FPM,php-fpm的master進程會監聽9000埠，然後給php-fpm work進程，work進程 再調用php-cgi解析器並且生成php執行環境再去執行解析對應的PHP文件
4，解析完成再返回給nginx,然後返回給瀏覽器。

註：
1，php-fpm會生成一個master進程用於監控9000埠，負責分發給下面的work進程
2，fastcgi 是一種協議用於解析器和伺服器之間的交互

Ⅵ php-fpm的簡介

PHP-FPM(FastCGI Process Manager：FastCGI進程管理器)對於PHP 5.3.3之前的php來說，是一個補丁包 ，旨在將FastCGI進程管理整合進PHP包中。如果你使用的是PHP5.3.3之前的PHP的話，就必須將它patch到你的PHP源代碼中，在編譯安裝PHP後才可以使用。
從PHP 5.4 RC2開始，php-fpm已經轉正了，不再被php團隊標注為EXPERIMENTAL（實驗性的東西） 。
相對Spawn-FCGI，PHP-FPM在CPU和內存方面的控制都更勝一籌，而且前者很容易崩潰，必須用crontab進行監控，而PHP-FPM則沒有這種煩惱。
PHP5.3.3已經集成php-fpm了，不再是第三方的包了。PHP-FPM提供了更好的PHP進程管理方式，可以有效控制內存和進程、可以平滑重載PHP配置，比spawn-fcgi具有更多優點，所以被PHP官方收錄了。在./configure的時候帶 –enable-fpm參數即可開啟PHP-FPM。
使用PHP-FPM來控制PHP-CGI的FastCGI進程
/usr/local/php/sbin/php-fpm{start|stop|quit|restart|reload|logrotate}
--start 啟動php的fastcgi進程
--stop 強制終止php的fastcgi進程
--quit 平滑終止php的fastcgi進程
--restart 重啟php的fastcgi進程
--reload 重新平滑載入php的php.ini
--logrotate 重新啟用log文件

Ⅶ php和nginx之間是如何工作的

Nginx+php-fpm實現原理 Nginx本身不會對PHP進行解析，終端對PHP頁面的請求將會被Nginx交給FastCGI進程監聽的IP地址及埠，由php-fpm作為動態解析伺服器處理，最後將處理結果再返回給nginx。其實，Nginx就是一個反向代理伺服器。Nginx通過反向代理功能將動態請求轉向後端php-fpm，從而實現對PHP的解析支持，這就是Nginx實現PHP動態解析的原理。 Nginx不支持對外部程序的直接調用或者解析，所有的外部程序（包括PHP）必須通過FastCGI介面來調用。FastCGI介面在Linux下是socket（這個socket可以是文件socket，也可以是ip socket）。為了調用CGI程序，還需要一個FastCGI的wrapper（wrapper可以理解為用於啟動另一個程序的程序），這個wrapper綁定在某個固定socket上，如埠或者文件socket。當Nginx將CGI請求發送給這個socket的時候，通過FastCGI介面，wrapper接收到請求，然後派生出一個新的線程，這個線程調用解釋器或者外部程序處理腳本並讀取返回數據；接著，wrapper再將返回的數據通過FastCGI介面，沿著固定的socket傳遞給Nginx；最後，Nginx將返回的數據發送給客戶端。
當nginx接收到一個http請求時，通過配置文件找到對應的server。然後匹配server中的所有location，找到最匹配的。而在location中的命令會啟動不同的模塊去完成工作，比如rewrite模塊、index模塊。因此在nginx中模塊可以看作真正的勞動工作者。nginx的模塊是被編譯到nginx中的，屬於靜態方式。啟動nginx時，模塊被自動載入。

Ⅷ php5-cgi和php5-fpm 這兩個東西是什麼意思啊有什麼區別怎麼使用

CGI

CGI全稱是逗公共網關介面地(Common Gateway Interface)，HTTP伺服器與你的或其它機器上的程序進行逗交談地的一種工具，其程序須運行在網路伺服器上。

CGI可以用任何一種語言編寫，只要這種語言具有標准輸入、輸出和環境變數。如php,perl,tcl等。

FastCGI

FastCGI像是一個常駐(long-live)型的CGI，它可以一直執行著，只要激活後，不會每次都要花費時間去fork一次（這是CGI最為人詬病的fork-and-execute 模式）。它還支持分布式的運算，即 FastCGI 程序可以在網站伺服器以外的主機上執行並且接受來自其它網站伺服器來的請求。

FastCGI是語言無關的、可伸縮架構的CGI開放擴展，其主要行為是將CGI解釋器進程保持在內存中並因此獲得較高的性能。眾所周知，CGI解釋器的反復載入是CGI性能低下的主要原因，如果CGI解釋器保持在內存中並接受FastCGI進程管理器調度，則可以提供良好的性能、伸縮性、Fail- Over特性等等。

FastCGI特點

FastCGI具有語言無關性.
FastCGI在進程中的應用程序，獨立於核心web伺服器運行，提供了一個比API更安全的環境。APIs把應用程序的代碼與核心的web伺服器鏈接在一起，這意味著在一個錯誤的API的應用程序可能會損壞其他應用程序或核心伺服器。 惡意的API的應用程序代碼甚至可以竊取另一個應用程序或核心伺服器的密鑰。
FastCGI技術目前支持語言有：C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby等。相關模塊在Apache, ISS, Lighttpd等流行的伺服器上也是可用的。
FastCGI的不依賴於任何Web伺服器的內部架構，因此即使伺服器技術的變化, FastCGI依然穩定不變。
FastCGI的工作原理

Web Server啟動時載入FastCGI進程管理器（IIS ISAPI或Apache Mole)
FastCGI進程管理器自身初始化，啟動多個CGI解釋器進程(可見多個php-cgi)並等待來自Web Server的連接。
當客戶端請求到達Web Server時，FastCGI進程管理器選擇並連接到一個CGI解釋器。Web server將CGI環境變數和標准輸入發送到FastCGI子進程php-cgi。
FastCGI子進程完成處理後將標准輸出和錯誤信息從同一連接返回Web Server。當FastCGI子進程關閉連接時，請求便告處理完成。FastCGI子進程接著等待並處理來自FastCGI進程管理器(運行在Web Server中)的下一個連接。 在CGI模式中，php-cgi在此便退出了。
在上述情況中，你可以想像CGI通常有多慢。每一個Web請求PHP都必須重新解析php.ini、重新載入全部擴展並重初始化全部數據結構。使用FastCGI，所有這些都只在進程啟動時發生一次。一個額外的好處是，持續資料庫連接(Persistent database connection)可以工作。

FastCGI的不足

因為是多進程，所以比CGI多線程消耗更多的伺服器內存，PHP-CGI解釋器每進程消耗7至25兆內存，將這個數字乘以50或100就是很大的內存數。

Nginx 0.8.46+PHP 5.2.14(FastCGI)伺服器在3萬並發連接下，開啟的10個Nginx進程消耗150M內存（15M*10=150M），開啟的64個php-cgi進程消耗1280M內存（20M*64=1280M），加上系統自身消耗的內存，總共消耗不到2GB內存。如果伺服器內存較小，完全可以只開啟25個php-cgi進程，這樣php-cgi消耗的總內存數才500M。
上面的數據摘自Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建勝過Apache十倍的Web伺服器(第6版)

PHP-CGI

PHP-CGI是PHP自帶的FastCGI管理器。

PHP-CGI的不足：

php-cgi變更php.ini配置後需重啟php-cgi才能讓新的php-ini生效，不可以平滑重啟。
直接殺死php-cgi進程，php就不能運行了。(PHP-FPM和Spawn-FCGI就沒有這個問題，守護進程會平滑從新生成新的子進程。）
PHP-FPM

PHP-FPM是一個PHP FastCGI管理器，是只用於PHP的，可以在 下載得到。

PHP-FPM其實是PHP源代碼的一個補丁，旨在將FastCGI進程管理整合進PHP包中。必須將它patch到你的PHP源代碼中，在編譯安裝PHP後才可以使用。

Ⅸ php如何把自身進程設置為系統進程

進程管理-防止進程成為僵屍進程

創建好了進程，那麼怎麼對子進程進行管理呢？

使用信號，對子進程的管理，一般有兩種情況：(推薦學習：PHP編程從入門到精通)

posix_kill()：此函數並不能顧名思義，它通過向子進程發送一個信號來操作子進程，在需要要時可以選擇給子進程發送進程終止信號來終止子進程；

pcntl_waitpid()：等待或返回fork的子進程狀態，如果指定的子進程在此函數調用時已經退出(俗稱僵屍進程)，此函數將立刻返回，並釋放子進程的所有系統資源，此進程可以避免子進程變成僵屍進程，造成系統資源浪費；

孤兒進程：父進程掛了，子進程被pid=1的init進程接管(wait/waitpid)，直到子進程自身生命周期結束被系統回收資源和父進程 採取相關的回收操作

僵屍進程：子進程exit退出,父進程沒有通過wait/waitpid獲取子進程狀態，子進程佔用的進程號等描述資源符還存在，產生危害：例如進程號是有限的，無法釋放進程號導致未來可能無進程號可用

**父進程中使用：pcntl_wait或者pcntl_waitpid的目的就是防止worker成為僵屍進程

作用：使用pcntl_wait()後，在子進程死掉後，父進程也會被停止**

最後我們通過下圖來簡單的總結和描述這個多進程實現的過程：

.png

進程管理-進程間通信

隊列：如Redis，推薦

socket：推薦

管道：實現復雜，且管道(pipe)，使用文件形式存在，存在硬碟IO性能瓶頸

信號：承載信息量少，不好管理

進程管理-切換為守護進程

使用&實現

php deadloop.php &

相關資源：Nginx使用的php-fpm的兩種進程管理方式及優化-其它代碼類資源...
打開CSDN APP，看更多技術內容

php 進程管理,PHP 進程管理器 PHP-FPM_阿喵看海外的博客
php-fpm是PHP的一個進程管理器。php下面的眾多work進程皆有php-fpm進程管理器管理。 php-fpm的工作原理 php-fpm全名是PHP FastCGI進程管理器。php-fpm啟動後會先讀php.ini,然後再讀相應的conf配置文件,conf配置可以覆蓋php.ini的配置。
繼續訪問
php-fpm解讀-進程管理的三種模式_april2nd的博客_php-fpm...
php-fpm進程管理一共有三種模式:ondemand、static、dynamic,我們可以在同一個fpm的master配置三種模式,看下圖1。php-fpm的工作模式和nginx類似,都是一個master,多個worker模型。每個worker都在accept本pool內的監聽套接字(linux已不存在驚...
繼續訪問
淺談PHP進程管理
這篇文章是對之前一篇文章的補充和改進, 創建一個主(master)進程，主進程安裝定時器，每隔5分鍾檢測一次隊列長度，根據隊列長度計算需要的worker進程， 然後創建或者殺掉子進程。這樣做的好處是防止隊列堆積，任務得不到及時處理。更新業務代碼，只需要reload操作即可。 整個流程有以下知識點： 創建守護進程的步驟: 設置默認文件許可權 fork一個進程，父進程退出 調用setsid創建一個新的會話 將當前工作目錄更改為根目錄 關閉不再需要的文件描述符 使用信號實現定時器 上一篇定時器依賴於系統的定時任務，這次使用鬧鍾信號實現，php 5.3.0以下的版本依賴於ticks，
php 腳本 fpm緩存,PHP生命周期及fpm(FastCGI進程管理器)的運作方式
PHP在web方式中如何改了文件就立即生效的，重要的幾個概念：sapi: 可以簡單的理解為php引擎對外的一個統一介面，使得php可以和外部程序進行交互php的生命周期中關鍵四個調用: MINT -> RINT -> RSHUTDOWN -> MSHUTDOWNfpm: fastcgi進程管理器fpm方式的流程就是:fpm通過sapi介面與php進程交互1.fpm啟動會調用各擴展...
繼續訪問
Linux下搭建PHP開發環境,Php-Fpm進程管理。_黑夜開發者的博客
目前PHP項目開發幾種比較流行的架構搭建中,LNMP在性能方面是最好的,正因為如此,使得LNMP架構逐漸流行起來,今天,前面提到了Nginx部署,由於項目實際環境的需要,今天就在說一下怎麼部署PHP。 環境 ...
繼續訪問
php而為,為高負載而生的 PHP 進程管理器 —— PHP-PM (PPM)
PHP-PM 可以用於php應用程序的進程管理,增壓和負載均衡.它使用 ReactPHP 實現php的事件驅動和非阻塞I/O。 它是基於 ReactPHP,最好是工作在基於請求-響應式的框架,像Symfony的HTTPKernel。這樣做是為了減少php啟動(包括變數聲明,載入和...
繼續訪問
最新發布 php進程管理
php 進程管理 tasks 過多
繼續訪問

PHP進程實現&管理
運行環境為Linux，模式為CLI DEMO /*要創建的子進程*/ $manager = [ 'work1', 'work2', 'work3', ]; /*當前進程名稱*/ $status = file_exists('/proc/' . getmypid() . '/status'); $bash = '-'; if ($status) { $bash = file('/proc/' . getmypid() . '/status', FILE_IGNORE.
繼續訪問
php的管理進程管理利器--php-fpm_weixin_33778778的博客
mod_php 模式是將php模塊安裝到apache中,所以每一次apache結束的請求呢,都會產生一條進程,這個進程就完整的包括php的各種運算計算等操作。 從圖中我們很清晰的可以看到,apache每接收一個請求,都會產生一個進程來連接php通過sapi來完成請求...
繼續訪問
php-frm進程管理,PHP內核探索-進程管理
進程管理方式首先我們了解一下php的三種不同的進程管理方式：static：靜態管理進程。在啟動時，master按照pm.max_children配置fork出對應數量的work進程，即work的進程是固定不變的。dynamic：動態管理進程。在fpm啟動時先按照pm.start_servers初始化一定數量的work進程，運行期間如果master發現空閑work進程低於pm.min_spare_s...
繼續訪問
理解php-fpm的兩種執行方式
前段時間配置php-fpm的時候，無意間發現原來他還有兩種執行方式。與Apache一樣，他的進程數也是可以根據設置分為動態和靜態的。關於Apache的工作方式及對應的設置方法，我已經在《Ubuntu下配置Apache的Worker模式》一文中寫出，這里不再多說。 而php-fpm也是同樣存在兩種方式，一種是直接開啟指定數量的php-fpm進程，不再增加或者減少；另一...
繼續訪問
php進程原理_PHP進程管理器php-fpm的工作原理
PHP進程管理器php-fpm的工作原理發布時間：2020-07-21 17:46:39來源：億速雲閱讀：133作者：小新今天小編給大家分享的是PHP進程管理器php-fpm的工作原理，相信很多人都不太了解，為了讓大家更加了解，所以給大家總結了以下內容，一起往下看吧。一定會有所收獲的哦。php-fpm是什麼php-fpm是PHP的一個進程管理器。php下面的眾多work進程皆有php-fpm進程管...
繼續訪問
如何管理php常駐進程,一看就懂系列之 如何實現與控制php常駐進程-Go語言中文社區...
前言關於如何實現與控制php常駐進程，不管是google還是上進行搜索，都沒有感覺看起來賞心悅目的解答，於是決定自己動手總結下。有同學會問了，整這個干甚？簡單的說就是，可以讓一個php腳本一直處於運行的狀態。從而實現將項目中某些耗時操作非同步化，進隊列後由php腳本取出再執行。有同學又會問了，直接在伺服器直接命令「php test.php &」，不就可以實現了？那麼這樣做的話有三點...
繼續訪問

PHP-FPM(PHP進程管理器)
PHP-FPM
繼續訪問

php 進程管理,從 0 到 1 優雅的實現 PHP 多進程管理
_| |_ __ __ _ _ __ _ _| |_ ___| '_ \ / _` | '__| | | | __/ _ \| | | | (_| | | | |_| | || (_) ||_| |_|\__,_|_| \__,_|\__\___/ .TIGERB.cnAn object-oriented multi process manager for PHPVersion: 0...
繼續訪問
php-fpm進程管理的三種模式
轉載自 php-fpm解讀-進程管理的三種模式 —程序媛大麗 標明轉載以示尊重 感謝原作者的分享。 php-fpm進程管理一共有三種模式：ondemand、static、dynamic，我們可以在同一個fpm的master配置三種模式，看下圖1。php-fpm的工作模式和nginx類似，都是一個master，多個worker模型。每個worker都在accept本pool內的監聽套接字（linu...
繼續訪問

php 進程管理那點事
之前本地開發和環境一直用的集成環境,最近新項目 集成了php7+nginx 跑了一段時間發現偶爾 有php進程退出的情況 排查原因 nginx log: 1111 upstream timed out (10060: A connection attempt failed because the connected party did not properly respond after ...
繼續訪問
從0到1優雅的實現PHP多進程管理
_ | | _ __ __ _ _ __ _ _| |_ ___ | '_ \ / _` | '__| | | | __/ _ \ | | | | (_| | | | |_| | || (_) | |_| |_|\__,_|_| \__,_|\__\___/ ...
繼續訪問
熱門推薦 php-fpm安裝、配置與優化
轉載自：https://www.zybuluo.com/phper/note/89081 1、php中fastcgi和php-fpm是什麼東西 最近在研究和學習php的性能方面的知識，看到了factcgi以及php-fpm，發現我對他們是少之又少的理解，可以說幾乎是一無所知，想想還是蠻可怕的。決定仔細的學習一下關於這方面的知識。 參考和學習了以下文章： 1. mod_php和
繼續訪問
php-fpm的兩種進程管理模式
php-fpm的兩種進程管理模式 php-fpm的進程數也是可以根據設置分為動態和靜態的。 一種是直接開啟指定數量的php-fpm進程，不再增加或者減少； 另一種則是開始的時候開啟一定數量的php-fpm進程，當請求量變大的時候，動態的增加php-fpm進程數到上限，當空閑的時候自動釋放空閑的進程數到一個下限。 這兩種不同的執行方式，可以根據伺服器的實際需求來進行調整。 這里先說一下涉及
繼續訪問
7、Php-Fpm進程管理
1、進程管理 php-fpm採用的是master-worker的進程方式。其中， master負責監聽埠，等待鏈接;其次，注冊信號，可以通過信息好master進行管理 worker負責處理具體的邏輯 如下圖所示 2、信號管理 master進程可以理解如下信號 信號 含義 INT, TERM 立刻終止 ...
繼續訪問
php進程式控制制
簡介 PHP的進程式控制制支持實現了Unix方式的進程創建, 程序執行, 信號處理以及進程的中斷。 進程式控制制不能被應用在Web伺服器環境，當其被用於Web服務環境時可能會帶來意外的結果。 這份文檔用於闡述每個進程式控制制函數的通常用法。關於Unix進程式控制制的更多信息建議您查閱 系統文檔中關於fork（2）,waitpid（2），signal（2）等的部分或更全面的參考資料比如 《Unix環境高級編程》
繼續訪問
php進程管理
php 進程管理

Ⅹ php-fpm怎麼連接的mysql

們都知道，php是不能直接操作 mysql的，他需要通過擴展提供介面調用，php的mysql擴展也好幾個，只支持面向過程的mysql，既支持面向過程也支持面向對象的mysqli，只支持面向對象的PDO，當然無論是那個擴展，也只是php語法寫法上的區別而已，底層其實是一樣的。
今天我們不講語法這些老掉牙的東西，我們隨便找一個擴展，來分析一下 php底層 和 mysql 之間的通信原理。
首先我們來理解一下 php-fpm 的工作原理，php-fpm 是一個 php-cgi 進程管理器，其實就是一個連接池，它和nginx配合的工作原理如下。
我們先從最簡單的靜態方式入手觀察他的工作原理
vim php-fpm.ini
[www]
pm = static
pm.max_children = 5
pm.max_requests = 2
上面三句話的含義是什麼呢:
1、static 表示靜態以靜態方式生成 php-fpm 進程
2、pm.max_children = 5 表示當 php-fpm 啟動時就啟動 5 個 php-fpm 子進程 等待處理 nginx 發過來的請求
3、pm.max_requests = 2 表示每個 php-fpm 子進程處理 2 個請求就銷毀，當然父進程每次看到有銷毀的自然也就會生成新的子進程
我們來簡單驗證一下這個說法：
首先重啟 php-fpm，讓它復位一下
接下來寫一條簡單的語句輸出當前進程ID
echo "當前 php-fpm 進程ID：".posix_getpid();
不斷刷新瀏覽器觀察輸出變化
當前 php-fpm 進程ID：24548
當前 php-fpm 進程ID：24549
當前 php-fpm 進程ID：24550
當前 php-fpm 進程ID：24547
當前 php-fpm 進程ID：24551
當前 php-fpm 進程ID：24548
當前 php-fpm 進程ID：24549
當前 php-fpm 進程ID：24550
當前 php-fpm 進程ID：24547
當前 php-fpm 進程ID：24551
當前 php-fpm 進程ID：24563
當前 php-fpm 進程ID：24564
當前 php-fpm 進程ID：24565
當前 php-fpm 進程ID：24566
當前 php-fpm 進程ID：24567
當前 php-fpm 進程ID：24563
當前 php-fpm 進程ID：24564
當前 php-fpm 進程ID：24565
當前 php-fpm 進程ID：24566
當前 php-fpm 進程ID：24567
當前 php-fpm 進程ID：24568
當前 php-fpm 進程ID：24569
當前 php-fpm 進程ID：24570
當前 php-fpm 進程ID：24571
當前 php-fpm 進程ID：24572
當前 php-fpm 進程ID：24568
當前 php-fpm 進程ID：24569
當前 php-fpm 進程ID：24570
當前 php-fpm 進程ID：24571
當前 php-fpm 進程ID：24572
可以看得出，第一批id不是按照順序執行的，進程id為24547的進程是在第四位處理的，然後從下面開始，所有id都是順序執行的而且每次生成的一批id都是遞增，是不是有種mysql自增主鍵的趕腳呢？
這里需要注意的是，無論是靜態還是下面的動態配置方式，只要沒有設置 max_requests ，那麼進程是不會銷毀的，也就是說當一個進程裡面出現死循環或者內存溢出等導致進程僵死的情況出現的時候，處理的進程就會少一個了
好吧理解了靜態的處理方式，我們其實也很容易知道這個方式的弊端了，當然我們平時伺服器不可能就開5個進程每個進程處理2個請求，我們來做一個簡單的加減乘除，看看一個伺服器應該開多少個 php-fpm 合適
首先我們來看看一個簡單的echo需要多少內存：
$size = memory_get_usage();
$unit = array('b','kb','mb','gb','tb','pb');
$memory = @round($size/pow(1024,($i=floor(log($size,1024)))),2).' '.$unit[$i];
echo "當前 php-cgi 進程所使用內存：".$memory;
觀察瀏覽器我們可以得到一下數據：
當前 php-cgi 進程所使用內存：227.17 kb
也就是說一個簡單的什麼都不幹的php就已經佔用了200多K的內存，當然這也不算多。
不過進程多了cpu切換進程速度就會變慢，所以這個數還是需要通過ab等測試工具才能測試出具體應該開多少比較合理
我們先從200開始，不斷的增加，架設增加到800的時候，效率和400一樣，那我們就沒必要開800那麼多進程浪費內存了。
那麼問題就來了，如果同一時間請求出超過400呢？有人說會排隊等待，真的會排隊等待嗎？答案明顯是 php-fpm 是沒能力排隊了，因為處理請求的php-fpm子進程都用完了，那麼等待也就只能是在 nginx 等待，通常一個 nginx 也不只是轉發請求給 php-fpm 就完事了，他還要處理靜態文件呢？如果這些php請求導致nginx的請求數過多一直在等待，那麼訪問靜態文件自然也會卡了，這時候我們就需要配置成下面的動態處理方式。
[www]
pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 8
;pm.max_requests = 2
上面五句話的含義是什麼呢:
1、dynamic 表示靜態以動態方式生成 php-fpm 進程
2、pm.max_children = 10 同時活動的進程數 10個
3、pm.start_servers = 5 表示當 php-fpm 主進程啟動時就啟動 5 個 php-fpm 子進程
4、pm.min_spare_servers = 2 表示最小備用進程數
5、pm.max_spare_servers = 8 表示最大備用進程數
6、pm.max_requests = 2 上面說過就不說了
當前 php-fpm 進程ID：2270
當前 php-fpm 進程ID：2271
當前 php-fpm 進程ID：2272
當前 php-fpm 進程ID：2273
當前 php-fpm 進程ID：2274
當前 php-fpm 進程ID：2270
當前 php-fpm 進程ID：2271
當前 php-fpm 進程ID：2272
當前 php-fpm 進程ID：2273
當前 php-fpm 進程ID：2274
當前 php-fpm 進程ID：2270
當前 php-fpm 進程ID：2271
當前 php-fpm 進程ID：2272
當前 php-fpm 進程ID：2273
當前 php-fpm 進程ID：2274