網站跑起來「感覺很慢」，卻問不出哪裡出了問題——這是許多站長最常遇到的困境。主機商的客服叫你看 CPU 使用率，外掛說要監控回應時間，坊間教學又把磁碟讀寫（Disk I/O）和記憶體（Memory）混在一起講，讓人越看越茫然，不知道該盯哪個數字才有意義。
有效的主機效能監控指標，其實集中在四個維度：處理器負載、記憶體用量、磁碟讀寫速度，以及終端用戶感受到的回應時間。掌握這四個維度的意義與警戒值，才能把「感覺很慢」轉化成可以行動的診斷結論。
CPU 使用率，看趨勢比看峰值重要
處理器使用率（CPU Utilization）是多數人最先盯的數字，卻也最容易被誤讀。單次峰值衝到 80% 並不代表主機有問題——電商活動流量湧入、或排程備份在深夜啟動，都可能讓使用率瞬間拉高後再回落。真正危險的不是峰值，而是使用率長時間維持在高位不回頭。若連續 10 分鐘以上都維持在 85% 以上，通常意味著有程序未釋放資源，或主機規格已不足以應付常態流量。
要觀察 CPU 趨勢，「過去 24 小時」的折線圖遠比當下快照有用。找一個流量平穩的工作日作為基準，把那段時段的平均使用率當作正常上限的參照，往後只要突破基準就能即時察覺異常。
跑排程任務的時段要單獨標記
WordPress 的備份、資料庫優化、搜尋索引重建，多數站長會把這些排程集中在深夜執行，結果在凌晨看到 CPU 使用率急升，誤以為遭受攻擊。解法是在監控儀表板上把這些排程時段標記出來，讓異常警報能排除這段「預期高峰」，只對真正非預期的高峰發出通知。
使用率偏低也不代表健康
CPU 長時間維持在 5% 以下，看似游刃有餘，有時卻代表另一種問題：資料庫查詢卡在 I/O 等待（I/O Wait），處理器其實在「等磁碟」而非「在運算」，使用率數字因此顯得正常。這個情況要靠下一節的磁碟讀寫指標才能揪出來。
記憶體用量，關鍵在可用量而非總用量
記憶體（RAM）監控的常見誤區，是只看「已用百分比」——看到 70% 就緊張，但作業系統本來就會把閒置記憶體拿來做快取，這部分隨時可被應用程式取回，並非真正的壓力。真正要盯的數字是可用記憶體（Available Memory），以及交換空間（Swap）的使用量。
一旦可用記憶體降到主機總量的 10% 以下，作業系統就會開始把記憶體內容搬到 Swap。Swap 通常建立在磁碟上，速度比 RAM 慢上百倍。這個切換在使用者眼中就是「網站突然變慢」，卻在 CPU 指標上幾乎看不出任何異常，因為處理器並未超載。
PHP 工作程序的記憶體上限值
WordPress 環境通常執行 PHP-FPM，每個 PHP 工作程序（Worker）都有各自的記憶體上限設定（memory_limit）。安裝多個外掛後，每次請求可能消耗 64 MB 到 128 MB 甚至更多。主機上同時能有幾個工作程序運作，取決於可用記憶體除以單一程序的消耗量。合理的做法是在非尖峰時段拉一次即時快照，確認 PHP-FPM 的活躍程序數距上限還有多少緩衝，不要等到容量真正耗盡才發現問題。
磁碟讀寫，PHP-FPM 無回應的幕後原因
磁碟讀寫速度（Disk I/O）是最容易被忽略、也最常是網站不穩的根本原因。機械式硬碟（HDD）與固態硬碟（SSD）的隨機讀寫效能差距可達數十倍。WordPress 的資料庫查詢本質上都是磁碟讀寫——若主機底層使用舊式 HDD，或是多個帳號共用讀寫頻寬的共享主機環境，磁碟就會成為整個系統的瓶頸。
判斷磁碟是否已成瓶頸，最直接的數字是 I/O 等待率（I/O Wait %）。這個指標代表「處理器有多少時間在等磁碟完成讀寫才能繼續執行」。一般建議 I/O Wait 不超過 10%；若持續維持在 20% 以上，就算 CPU 和記憶體數字都正常，網站的回應速度照樣會下降。
資料庫快取可以大幅減輕磁碟壓力
WordPress 預設依賴 MySQL 的查詢緩衝（Query Cache），但頻繁更新內容的站台快取命中率不高。加入 Redis 或 Memcached 這類記憶體快取層，可以把重複的資料庫查詢結果存入 RAM，讓磁碟讀寫量直接下降。若監控顯示讀寫使用率偏高，優先考慮這個方向，比直接替換更快的磁碟更具成本效益。
回應時間，最接近使用者真實感受的數字
前三個維度都是主機「內部健康指標」，而回應時間（Response Time）才是使用者實際感受到的效能。它的定義是從 HTTP 請求發出到收到第一個位元組——即首位元組時間（TTFB，Time To First Byte）——所花的時間。Google 的核心網頁指標（Core Web Vitals）建議 TTFB 在 800 毫秒以內為理想，超過 1,800 毫秒就進入需要優化的紅區。
回應時間同時受 CPU、記憶體、磁碟讀寫，甚至網路延遲的共同影響，因此常被拿來作「主機整體健康的晴雨表」。當回應時間突然拉長，再回頭對照前三個維度，才能精確定位是哪個環節出了問題。
設定地理分散的探測點
若只從台灣的監控伺服器量測回應時間，有可能遺漏日本、美國、東南亞用戶的延遲問題。多數免費監控服務都支援在不同地理位置佈建探測點（Probe），建議至少設台灣、日本、美國西岸三個位置。這樣才能區分「全球都慢」還是「只有特定地區慢」——兩種情況的解法截然不同。
免費工具怎麼設警報，才不會警報疲勞
工具的選擇常陷入兩個極端，一是功能太少不夠用，二是設了一堆警報卻無人處理。UptimeRobot 的免費方案提供每 5 分鐘一次的回應時間探測，支援 HTTP 狀態碼、回應時間超過閾值的 Email 通知，對中小型 WordPress 站台已足夠。New Relic 的免費版則在應用效能監控（APM）層面更為深入，可以看到每次 PHP 請求消耗多少時間在資料庫查詢、外部 API 呼叫，甚至逐行追蹤慢查詢。
警報設定的核心原則是分級，而非統一敏感度：
- 即時告知（Email 或 SMS）：網站完全無回應、HTTP 5xx 錯誤持續超過 2 次探測、回應時間超過 3,000 毫秒
- 每日摘要（Email 彙整）：CPU 使用率日均值超過 70%、可用記憶體低於 20%、磁碟使用量超過 80%
- 只記錄不通知：I/O Wait 偶爾超過 10%、單次回應時間尖峰
分層設定的好處是，真正需要立即處理的事件才會發出警示，日常波動自然沉澱到每日摘要，不會因為每天收到大量警報而養成直接忽略的習慣。
UptimeRobot 的回應時間警報設定方式
在 UptimeRobot 儀表板新增監控器（Monitor）後，進入該監控器的設定頁，找到「Alert Contacts」下方的「Advanced」選項，啟用「Response Time Alert」，分別設定「警告閾值（Warning Threshold）」和「嚴重閾值（Critical Threshold）」。建議初期將警告值設在 2,000 毫秒、嚴重值設在 4,000 毫秒，跑一週後再根據自己站台的正常回應時間基準調整，而非直接套用網路教學的數字。
New Relic 的慢查詢追蹤設定
安裝 New Relic PHP 代理程式（Agent）後，在 APM 的「Transactions」頁面可以找到「Slowest average response time」排行。點入單筆交易，可以看到資料庫查詢的瀑布圖（Waterfall）。預設的 Apdex 閾值（T 值）是 0.5 秒，在 WordPress 站台建議調整至 1.0 秒——過低會讓多數請求都顯示為「不滿意」，反而遮蔽了真正需要優化的部分。