PHP 網站效能極致化指南：Nginx、PHP-FPM、OPcache 與 MySQL 參數調校與主機規格對應方案

在大型內容網站、數位媒體或電商系統中，PHP 憑藉著極其成熟的生態系（如 Drupal、WordPress 或 Laravel）佔據著重要地位。然而，當網站遭遇瞬時流量衝擊或行銷活動時，許多伺服器常因預設參數未經調校而出現 502 Bad Gateway、504 Gateway Timeout 或 CPU 100% 爆滿的癱瘓問題。

要讓 PHP 網站達到極致效能，不能僅靠盲目升級硬體規格，更需要針對 Nginx、PHP-FPM、OPcache 與 MySQL 四大核心層級進行深入底層的參數調校。

PHP 效能優化的核心思維在於：消除不必要的硬碟 I/O、將動態編譯結果鎖在 RAM 記憶體中、正確計算進程上限防止記憶體溢出（OOM），並優化網路與資料庫緩衝區。

一句話重點

透過合理的 OPcache 記憶體快取、精算 PHP-FPM pm.max_children 防止記憶體溢出、優化 Nginx 異步連線與 Socket 佇列，以及配置 MySQL innodb_buffer_pool_size，能讓 PHP 網站同硬體規格下的每秒處理請求數（RPS / QPS）提升 3 至 5 倍。

它解決什麼問題？

傳統未調校的 PHP 伺服器運作時常見的四大效能災難包括：

1. 每次 HTTP 請求重複解析與編譯 PHP 腳本：浪費大量 CPU 運算資源在重複的 Opcode 編譯上。
2. PHP-FPM 進程開太多造成 OOM (Out of Memory)：Worker 進程無節制生成，擠爆實體記憶體，觸發 Linux OOM Killer 或造成頻繁的 Disk Swapping，導致系統卡死。
3. Nginx 與 PHP-FPM 連線池不匹配：Socket 佇列（Backlog）溢出，造成大量 HTTP 502 Bad Gateway 或 504 Timeout 錯誤。
4. MySQL 頻繁讀取磁碟 I/O：資料庫未充分利用記憶體緩衝區（Buffer Pool），慢查詢（Slow Queries）導致網頁載入卡在 DB 讀取階段。

核心調校四大層級細節解析

1. OPcache：將 PHP 腳本編譯結果鎖在記憶體中

PHP 屬於直譯型語言。在預設情況下，每一次 HTTP 請求都必須經歷「讀取 .php 檔 ➔ 語法解析 ➔ 編譯成 Opcode ➔ 執行 Opcode」的過程。開啟並優化 OPcache 後，可將編譯後的 Opcode 直接快取在共享記憶體中，省去前三個耗時步驟。

核心參數配置（在 php.ini）：

[opcache]
opcache.enable=1
opcache.enable_cli=1

; 分配足夠的共享記憶體給 Opcode 快取 ( MB )
; 大型 Drupal / WordPress 建議至少 256MB ~ 512MB
opcache.memory_consumption=256

; 字串快取池大小 ( MB )，專門快取類別名稱、函數名稱等重複字串
opcache.interned_strings_buffer=32

; 最大快取的腳本檔案數量 ( 建議設定大於網站專案檔案總數 )
opcache.max_accelerated_files=30000

; 檢查檔案變動的時間間隔 ( 秒 )
; 正式生產環境建議設為 0，並搭配發布腳本手動清除 OPcache，可達成 0 磁碟 I/O 驗證
opcache.validate_timestamps=0
opcache.revalidate_freq=0

; 開啟快速關閉機制，加速記憶體釋放
opcache.fast_shutdown=1

2. PHP-FPM：精算記憶體與進程數 (pm.max_children)

PHP-FPM (FastCGI Process Manager) 管理著處理 PHP 請求的 Worker 進程。進程開太少會導致 HTTP 請求排隊等待；進程開太多則會直接擠爆 RAM 記憶體。

核心計算公式：

pm.max_children = ( 總實體記憶體 RAM - OS系統預留 1GB - MySQL預留記憶體 - Nginx預留記憶體 ) / 單一 PHP 進程平均記憶體用量 (約 35MB ~ 65MB)

範例計算：在一台 8GB RAM 的伺服器上，假設分配 4GB 給 MySQL、1GB 給 OS/Nginx，剩餘 3GB (3072MB) 給 PHP-FPM。若單一進程耗用 50MB，則 pm.max_children 應設定為 3072MB / 50MB ≈ 61。

進程管理模式選擇：

• pm = static（推薦用於生產環境）：在服務啟動時一次性建立固定數量的 Worker 進程。優點是避免在流量瞬間衝高時，CPU 耗費資源頻繁 fork 新進程。
• pm = dynamic（適用於記憶體較小或多租戶環境）：動態調整進程數量。

核心參數配置（在 php-fpm.d/www.conf）：

[www]
pm = static
pm.max_children = 60

; 單一 Worker 進程累積處理指定次數請求後自動重置，防止第三方套件記憶體洩漏 (Memory Leak)
pm.max_requests = 1000

; Unix Socket 連線佇列長度，當併發量高時需放大此數值防止 502
listen.backlog = 8192

; 使用 Unix Domain Socket 替代 TCP 埠（如 127.0.0.1:9000），可減少 TCP 握手開銷並提升 5%~10% 效能
listen = /run/php/php-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

3. Nginx：高併發網絡事件與 Socket 佇列調校

Nginx 作為最前端的高效能 Reverse Proxy，負責接管大量 HTTP 外部連線，並透過 Socket 高效傳遞給後端的 PHP-FPM。

核心參數配置（在 nginx.conf）：

user www-data;
worker_processes auto;          # 自動依 CPU 核心數配對
worker_cpu_affinity auto;       # 自動繫結 CPU 核心，減少 Context Switch
worker_rlimit_nofile 65535;     # 提升單一進程可開啟的最大檔案描述符數

events {
    worker_connections 8192;    # 單一 Worker 進程的最大連線數
    multi_accept on;            # 收到新連線通知時盡可能多地接受連線
    use epoll;                  # Linux 平台最高效的異步 I/O 事件模型
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    # 開啟零複製 (Zero-Copy) 技術，提升靜態檔案傳送效率
    sendfile        on;
    tcp_nopush      on;
    tcp_nodelay     on;

    keepalive_timeout  65;
    types_hash_max_size 2048;

    # Gzip 動態壓縮設定，減少傳輸頻寬消耗
    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 5;          # 壓縮等級 5 達到效能與體積最佳平衡
    gzip_min_length 256;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml;

    # 快取 FastCGI 傳回結果（針對不常變動的頁面，大幅降低 PHP 負擔）
    fastcgi_read_timeout 300;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 256 16k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
}

4. MySQL (InnoDB)：資料庫記憶體緩衝區極致化

資料庫效能優化的金科玉律是：讓熱點資料（Indexes & Tables）盡可能保留在 RAM 記憶體中，遠離慢速磁碟。

核心參數配置（在 my.cnf 或 mysqld.cnf）：

[mysqld]
# 專用 DB 伺服器可設為 RAM 的 70%-80%；同機部署建議設為總 RAM 的 40%-50%
innodb_buffer_pool_size = 4G

# 設定 Buffer Pool 實例數量，減少大型記憶體佇列鎖競爭 (建議每 1GB 分配 1 個 instance)
innodb_buffer_pool_instances = 4

# 日誌檔案大小，較大的設定能減少 Checkpoint 刷盤頻率
innodb_log_file_size = 512M
innodb_log_buffer_size = 64M

# 交易刷盤策略（設為 2 能大幅提升寫入效能，每秒刷盤一次，平衡效能與安全性）
innodb_flush_log_at_trx_commit = 2

# 直接繞過作業系統 Page Cache，避免雙重快取 (Double Buffering) 浪費記憶體
innodb_flush_method = O_DIRECT

# 提升資料庫最大連線數上限，防止 Too many connections
max_connections = 500

# 關閉不必要的查詢快取（MySQL 8.0 已移除，舊版建議關閉）
# query_cache_type = 0

主機規格與對應配置建議方案 (Single-Node)

當 Nginx + PHP-FPM + OPcache + MySQL 部署在同一台單機伺服器（Single-Node）時，請參考以下針對不同硬體規格調校的量化配置參數：

運維架構分水嶺：當單機流量突破 32GB RAM 與 8,000 RPS 瓶頸時，建議採用 讀寫分離 / 獨立 DB 主機、Redis 記憶體快取層 與 Load Balancer 架構，進行水平擴充（Horizontal Scaling）。

它與預設配置有什麼不同？

非工程背景的人需要知道什麼？

1. 「升級硬體」不等於「網站變快」：如果花錢升級到 32G 記憶體的主機，但 MySQL 的 innodb_buffer_pool_size 依然維持預設的 128MB，資料庫運作速度依然會被硬碟限制住。
2. 部署新版程式碼時需重置快取：若開啟了最高效能的 opcache.validate_timestamps=0，在部署新程式碼後必須執行重新載入指令（如 systemctl reload php-fpm），否則網站會繼續執行記憶體中的舊版程式碼。

適合誰使用？

• WordPress / Drupal / Laravel 網站管理者：希望在不增加伺服器預算的前提下，將現有主機效能發揮到極致。
• DevOps 與 Linux 系統管理員：為高併發 PHP 站點提供量化、可驗證的伺服器調校標準。

實戰 Prompt：用 AI Agent 指揮全新主機自動完成極致配置

如果你手邊有一台全新的 Linux VPS / 主機（例如 Ubuntu 24.04 LTS），你可以直接複製以下提示詞（Prompt）貼給你的 AI Agent（如 Antigravity CLI、Cursor 或 Claude Code）。AI Agent 會自動檢測你的硬體規格（CPU/RAM），精算出最佳參數，並自動寫入對應的設定檔與重啟服務：

你是一位精通 Linux 效能優化與高併發架構的高級 DevOps 專家。
我現在有一台全新的 Ubuntu 伺服器，請幫我建立一套極致效能的 Nginx + PHP-FPM 8.3 + OPcache + MySQL 8.0 環境：

【執行步驟要求】：
1. 檢測當前主機的 CPU 核心數與總 RAM 記憶體大小。
2. 根據記憶體總量，預留 1GB 給系統 OS、40% 給 MySQL innodb_buffer_pool_size、其餘分配給 PHP-FPM。
3. 自動計算出單一 PHP 進程大小，並以 `pm = static` 模式設定 `pm.max_children`，確保高併發時絕不溢出記憶體 (OOM)。
4. 配置 OPcache (分配 256MB+ 共享記憶體、設定 validate_timestamps=0、interned_strings_buffer=32)。
5. 配置 Nginx 使用 Unix Domain Socket 連接 PHP-FPM，啟用 worker_rlimit_nofile 65535、epoll、sendfile 與 Gzip 壓縮。
6. 配置 MySQL 的 innodb_buffer_pool_size、innodb_log_file_size 與 O_DIRECT。
7. 自動寫入對應設定檔並驗證語法，最後重新啟動所有服務並輸出系統資源檢視清單。

來源

• PHP 官方 OPcache 文件：https://www.php.net/manual/en/book.opcache.php
• Nginx 高效能調校指南：https://www.nginx.com/blog/tuning-nginx/
• MySQL InnoDB Buffer Pool 官方說明：https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool-resize.html
• 查閱日期：2026-07-24