一個請求在 PHP 裡經過的階段

PHP 的執行分成兩層生命週期：程序層與請求層。程序層的工作每個程序只做一次，請求層的工作每個請求都做一次。

請求結束那一步的範圍很大：全域變數、函式內的 static 變數、類別的靜態屬性、開過的檔案與一般的資料庫連線，全部在這一步釋放。下一個請求就算由同一個程序處理，也看不到上一個請求留下的任何 PHP 變數。這個設計叫 shared-nothing：請求之間不共享應用程式的狀態，每個請求從空白開始（見 Shared-nothing 請求模型）。

這件事可以直接量。下面這支腳本每次執行都把函式內的 static 變數與一個全域變數加一，並印出處理它的程序編號：

1<?php
2function counter() { static $n = 0; return ++$n; }
3$GLOBALS['g'] = ($GLOBALS['g'] ?? 0) + 1;
4echo "pid=", getmypid(), " static=", counter(), " global=", $GLOBALS['g'], " sapi=", PHP_SAPI, "\n";

在 Nginx 加 PHP-FPM 的環境連續請求四次，輸出是：

1pid=7 static=1 global=1 sapi=fpm-fcgi
2pid=6 static=1 global=1 sapi=fpm-fcgi
3pid=7 static=1 global=1 sapi=fpm-fcgi
4pid=6 static=1 global=1 sapi=fpm-fcgi

兩個程序（PID 6 與 7）輪流處理請求，同一個程序處理第二次時，兩個計數器仍然是 1。程序活了下來，PHP 變數沒有。

請求結束後留在程序裡的資源

請求結束只清掉 PHP 程式碼建立的變數，程序本身持有的資源可以跨請求存在，而且只有程序活得夠久時才有意義：

• OPcache：把編譯好的 opcode 存在共享記憶體裡，下一個請求不必重新編譯同一個檔案。它的效果完全取決於程序活多久，在 OPcache 與程序壽命 展開。
• 持久連線：PDO 開了 PDO::ATTR_PERSISTENT 的資料庫連線，請求結束時不關閉，留給同一個程序的下一個請求重用。
• APCu 這類記憶體快取擴充：資料放在程序（或程序群共用）的記憶體裡，請求結束不清除。

所以 shared-nothing 的精確範圍是「PHP 程式碼建立的狀態」。程序層的資源由程序壽命決定，而程序壽命由下一節的 SAPI 決定。

SAPI：PHP 直譯器與外部環境之間的介面

SAPI（Server API）是 PHP 核心與外部環境之間的一層。PHP 的直譯器本身不知道請求從哪裡來：它可能被命令列啟動、被 web 伺服器 fork 出來、被嵌在 Apache 裡、或在一個常駐的伺服器裡被呼叫。SAPI 負責兩件事：把外部環境帶來的請求翻譯成 PHP 認得的形式（填好 $_SERVER、$_GET，把請求內容交給 php://input），以及把 PHP 的輸出與回應標頭交回外部環境。同一份 PHP 核心配上不同的 SAPI，就是不同的執行方式（見 SAPI）。

程式裡可以用 PHP_SAPI 常數（或 php_sapi_name()）讀到目前的 SAPI 名稱。上一節的輸出裡 sapi=fpm-fcgi 就是這個值。實測過的幾種：

cgi-fcgi 這個名字反映了一件事：php-cgi 同一支程式能以兩種協定運作。CGI 與 FastCGI 是兩個不同的協定，FastCGI 沿用 CGI 傳遞請求資訊的那套參數名稱，改掉的是程序壽命。被 web 伺服器以 CGI 執行時，php-cgi 處理完一個請求就結束；以 FastCGI 模式啟動時，它常駐下來接收多個請求。兩者的差別在 CGI 與 FastCGI 兩篇分別說明。

比較執行模型的三個問題

SAPI 的種類很多，而它們之間的差異可以歸到三個問題上。每一種執行模型對這三個問題各有一組答案，後面的行為差異幾乎都從這組答案推得出來。

直譯器住在哪裡。 PHP 直譯器可能住在 web 伺服器自己的程序裡（mod_php），也可能住在另一個獨立的程序裡（CGI、PHP-FPM），或住在某個程序的執行緒裡（FrankenPHP）。住在 web 伺服器外面時，web 伺服器與 PHP 之間需要一種溝通方式，CGI 與 FastCGI 就是這種方式。這也決定了誰對外講 HTTP：直譯器住在 web 伺服器外面時，PHP 這一側只收得到 web 伺服器翻譯過的請求。

執行它的程序活多久。 程序可能只活一個請求（CGI），也可能活過成千上萬個請求（mod_php、PHP-FPM、FrankenPHP）。程序活得越久，程序層的工作（讀設定、載入擴充）攤在越多請求上，OPcache 這類程序層的快取也才有編譯結果可以重用。

應用程式的狀態活多久。 在 shared-nothing 的模型裡，狀態只活一個請求，框架每個請求都要重新啟動一次：載入設定、註冊服務、建立路由表。常駐 worker 模式（FrankenPHP 的 worker 模式、Laravel Octane）讓應用程式啟動一次後留在記憶體裡，狀態活過很多個請求，省下每次重新啟動框架的成本，代價是上一個請求留下的變數與物件會被下一個請求看到：放在靜態屬性裡的「目前登入的使用者」會被下一個使用者的請求讀到，每個請求往靜態陣列加資料的程式會讓記憶體隨請求數一路增長。

這張表裡最容易混在一起的是程序壽命與應用程式狀態壽命這兩欄，而它們是兩件獨立的事：FrankenPHP 的傳統模式只有一個程序、而且一直不結束，同一支計數腳本在它上面跑三次，三次的 PID 都是 1、計數器三次都是 1；換成 worker 模式，PID 仍然是 1，計數器變成 1、2、3、4。程序一樣常駐，差在 PHP 有沒有在請求之間清空狀態。

三個問題各自展開的位置

這個模型的三個問題，每換掉一個答案就走到另一種執行模型：

• 把直譯器放在每個請求新啟動的程序裡，就是 CGI：最簡單的隔離，每個請求付一次啟動 PHP 的成本。
• 把直譯器放進 web 伺服器的程序裡，就是 mod_php：省掉啟動成本，代價是 web 伺服器的每個程序都帶著整個 PHP，包括只負責送圖片的那些。
• 把直譯器放在 web 伺服器外面、讓程序常駐，需要一個讓兩邊溝通的協定，就是 FastCGI；管理那群常駐程序的實作是 PHP-FPM。
• 讓程序活得更久對效能的意義集中在 OPcache：程序壽命從一個請求變成很多個請求時，被重用的是什麼。
• 讓應用程式的狀態也活過很多請求，就是 常駐 worker 模型：框架只啟動一次，同時失去 shared-nothing 的隔離。