PHP Workers 是高性能主機中都可以看到它的影子，也是這些主機中的重要組成的一部分，在本文中我以簡單的例子解釋解基礎知識，並與 WordPress 之間的運作關係。
目錄：
- 什麼是 PHP Worker ?
- PHP Worker 和 CPU
- PHP Worker 與 WordPress 性能的關係
- Nginx PHP-FPM 的設定
最早的時候，剛接觸 Kinsta 和 WP Engine 高性能主機商時，一點都不懂 PHP Worker 是甚麼東西，網路上也查不到甚麼資料，詢問官方，也說得很含糊。(心想，這是 WP Engine 創造出來的新名詞吧 !)
既然 WP Engine 創造了 PHP Workers 這個名詞，其他的主機商也就相繼開始學習使用：
- WP Engine (PHP Workers 數量，沒有說明)
- FlyWheel (PHP Workers 數量，沒有說明)
- Kinsta (基本方案 PHP Workers 2 個)
- Closte (基本方案 PHP Workers 6 個)
- Servebolt (任何方案 PHP Workers 數量無上限)
- Pagely (任何方案 PHP Workers 數量無上限)
- Pressable (PHP Workers 數量，沒有說明)
PHP Workers 的數量沒有所謂的「無上限」，只能把它當作一個招攬廣告名詞來看。
這就像是有些主機託管商，會說：給你無限流量、無限空間使用的意思一樣，廣告招攬的手法。
以 Kinsta 為例：
WordPress 基本方案 30 美金有 2 個 PHP Workers，而 WooCommerce 需要 4 個 PHP Workers 方案，100 美金 / 月 (官方要求)
雖然基本方案 30 美金 / 月，你一樣可以安裝 WooCommerce 外掛，但是，當 2 個 PHP Workers 不夠用時。
這些 WordPress 高性能主機商，這就開啟 PHP Worker 控制效能的大招，之後也就最被使用者詬病的，需要花大量金錢去購買 PHP Worker 數量。
也就為什麼許多使用者，雖然用不到這麼多的資源，卻被迫要選擇更昂貴的方案，正是因為這個原因。
什麼是 PHP Worker ?
在 WordPress 中 PHP Worker 建構頁面、處理預定的後台任務等，由於 PHP Worker 直接負責生成 HTML 頁面以服務於你網站的訪問者，因此，PHP Worker 決定了你的網站在任何時間，可以同時處理沒有快取的數量。
所以，它的工作流程是這樣的
瀏覽器 (造訪者) <<>> Nginx <<>> PHP (PHP Workers) <<>> MySQL
簡單的說：
讀者透過瀏覽器造訪你的網站，這個請求會經由 Nginx 傳給 PHP，PHP Workers 會向資料庫要資料；資料庫將所需的資料拿給 PHP Workers，PHP Workers 整理好資料回傳給 Nginx；讀者 (客戶端) 就可以看到你的 HTML 網頁。
對一般的部落格網站，快取在這時候的腳色就很重要了，
快取機制在 Nginx <<>> PHP (PHP Workers) 之間就會出來攔截資料，直接把手上準備好的資料就回交給 Nginx，Nginx 接到已快取的資料，再傳送到讀者的瀏覽器，呈現我們的網頁讓讀者閱讀，反而 PHP Workers 和 MySQL 就閒在那沒事做。
如果很不幸，快取沒有命中，PHP Worker 還是會接收請求，去找資料庫拿資料。
主機端的 FastCGI Cache 快取運作是如此。(這跟 WP 快取外掛運作又有一點點不同)
反觀，對高動態 WooCommerce 和 LMS 教學網站， PHP Workers 就特別格外的特別重要。
通常，當一件商品放入購物車後及會員登入網站觀看課程後，網站快取狀態會消失，而會看到大量未快取的請求。因此，這些網站將需要大量的 PHP Workers 來確保每個請求都得到處理而不會出現延遲或超時。
PHP Workers 和 CPU
PHP 是單一執行緒 (single-threaded) 工作 (但也可以透過 pThreads 成為多行程，但不在的說明內)
所以，WordPress 也是一個單一執行緒 CMS 程式 (每個 PHP worker 只能使用一個 CPU core)
例如：
你有 4 個 PHP Workers，但是你的 VPS 主機的 CPU 是單核心 (1 core)
這時，4 個 Workers 無法同時工作，它們會成為列隊，等待第一個 Worker 完成工作輪到下一個 Workers 接手。
如果是 CPU 核心不足，PHP Workers 的列隊等待過久，也就會回應 504 的錯誤。
從上述的結論來看，得到一個結果：
看到這邊，心想 PHP Workers 多一點，是不是就可以處理更多的請求，做更多的事情。
理論上是這樣沒錯，但需要 CPU 多核心的配合才行。
把 CPU 當作一個消防栓，接上一個管子 (PHP Worker) 噴水，水壓很強噴的很遠。如果，接上 10 根水管 (PHP Workers) 噴水，水壓是不是一樣很強噴的很遠。
這時，PHP Workers 與 CPU 的搭配就會是一個重要的配置了。
也因為 WordPress 是一個單一執行緒 (single-threaded) CMS 程式，在 Kinsta 測試中發現，CPU 高時脈速度就變得非常重要。
也就可以理解 Kinsta 為何特別喜愛 GCP C2 (Intel 3.8 GHz) VM 的道理，其他 CPU 3.8 GHz 高時脈產品的 VPS 主機 (Vultr High Frequency) 也受到特別歡迎。
PHP Workers 與 WordPress 性能的關係
WordPress 本身是一個單一執行緒 (single-threaded) CMS 程式，也就是說一個 WordPress 請求（頁面加載、搜尋請求、產品過濾等等），無論請求多麼的複雜，都由一名 PHP Worker 處理，多個 PHP Workers 不會參與 WordPress 多個不同方面來的請求。
所以，一個 WordPress 請求：
- 一位讀者用瀏覽器進入你的網站。
- 瀏覽器與你的主機聯絡 (Nginx) 請求網頁加載需的資料。
- Nginx 首先判斷是否可以直接從快取中的請求，或是交由 PHP 處理。
- 如果需要 PHP 處理，你的 PHP Workers 會被分配，並將開始處理必要的代碼。
- 如果又需要資料庫的資料，PHP Workers 向資料庫發送查詢，然後等待資料庫結果回覆。
- PHP Workers 從資料庫中獲取資料後，繼續處理，完成後，PHP Workers 在送回 Nginx。
- Nginx 接到 PHP workers 的回覆後，在傳送到讀者的瀏覽器，呈現我們美美的網頁。
在我沒搞懂 PHP Worker 之前，一直以為 WordPress 高動態網站的瓶頸在資料庫的搜尋上，其實不然。
在我實際的代管購物車和教學網站中，往往最擔心的是客製外掛和外掛濫用，
往往在 16 個 PHP Workers 的網站中，外部請求數不需太多，就會被這些不良的客製外掛或過多不必要的外掛給消耗殆盡，甚至造成記憶體不足。
一個好的輕量的外掛代碼，可以讓 PHP Worker 更快速的工作，在很短的時間內完成工作，換下個列隊的 PHP 代碼，更快速的交由資料庫搜尋資料。網站更可以承接更多的外部請求。
PHP Workers 不足的結果
為了讓 WordPress 網站可以獲得快速可靠的性能，需要確保網站有足夠的 PHP Workers 很重要。
反之，你的伺服器的 CPU 和 RAM 可用資源太少之下，過多的 PHP Workers 有可能會消耗伺服器的所有資源並佔用伺服器執行緒。
當 PHP Workers 已經在網站上忙碌時，它們開始建立隊列，由於 PHP Workers 不足而又超時，網頁載入開始變得緩慢，就會在瀏覽器看到 502 bad gateway errors 錯誤，
這就好比我們去一家餐廳用餐 (網站)，我們 (造訪者) 會在門口等服務生來帶位，PHP Workers 比如是服務生，
2 個 PHP Workers 有如 2 個服務生可以同時來帶位，
第 3 個客人 (造訪者) 就需在餐廳門口等待服務生 (PHP Workers) 帶位，當 PHP Workers 已經在網站上忙碌時，造訪者開始建立列隊 (門口排隊)。
如果，服務生帶位 + 點餐的動作太慢 (CPU)，門口一定會塞滿要用餐的客人，服務生不足又加上等待的客人太多，網頁就會顯示 502 bad gateway errors 錯誤。
為了解決這個問題，在 CPU 尚未達到極限的情況下增加 PHP Workers 是必要的，而且可以提高網站性能。
Nginx PHP-FPM 的設定
曾嘗試問過 Kinsta 客服，這個 PHP-FPM 的設定問題，可惜這是商業機密，問不出所以然，每一家主機商有自己的配方。
在大多數 Nginx 伺服器上，PHP Worker 是由 FastCGI 管理處理序，也就是 PHP-FPM。
pm.max_children 相當於 PHP Worker，也就是可以同時存活的最大 Workers 數量。
尋找 PHP-FPM 的甜蜜點：
PHP Workers 是一個很複雜的知識，在自架 VPS 中，你需要不斷反覆的測試，花大量的時間，找出適合你的伺服器 PHP-FPM 配置。
發佈留言