如何判斷伺服器瓶頸、迅速修正瓶頸、改善伺服器效能，以及避免日後再次發生效能問題。
總覽
本指南將說明如何在 4 個步驟中修正超載的伺服器：
評估
當流量超載伺服器時，下列一或多項項目可能會成為瓶頸：CPU、網路、記憶體或磁碟 I/O。找出其中的瓶頸，就能將精力集中在最有效的緩解措施上。
- CPU：CPU 使用率持續超過 80%，應進行調查並修正。CPU 使用率達到 80% 到 90% 時，伺服器效能通常會降低，且隨著使用率接近 100%，效能下降的情況會更加明顯。單一要求的 CPU 使用率不算高，但在流量尖峰期間大量執行這項作業，有時會讓伺服器不堪負荷。將服務卸載至其他基礎架構、減少耗費高的作業，以及限制要求數量，都能降低 CPU 使用率。
- 網路：在流量高峰期間，滿足使用者要求所需的網路傳輸量可能會超過容量。部分網站 (視主機供應商而定) 可能會達到累積資料傳輸上限。縮減與伺服器之間傳輸的資料大小和數量，即可消除這個瓶頸。
- 記憶體：當系統記憶體不足時，資料就必須卸載到磁碟儲存。磁碟的存取速度比記憶體慢許多，這可能會導致整個應用程式速度變慢。如果記憶體完全耗盡，可能會導致記憶體不足 (OOM) 錯誤。調整記憶體分配、修正記憶體流失問題，以及升級記憶體，都可以消除這個瓶頸。
- 磁碟 I/O：從磁碟讀取或寫入資料的速率受到磁碟本身的限制。如果磁碟 I/O 是瓶頸，增加記憶體中快取的資料量可以緩解這個問題 (但會增加記憶體使用率)。如果這樣做無法解決問題，可能就需要升級磁碟。
本指南中的技巧著重於解決 CPU 和網路瓶頸問題。對大多數網站而言，CPU 和網路會是流量激增期間最相關的瓶頸。
在受影響的伺服器上執行 top，是調查瓶頸的好起點。如果可行，請補充代管服務供應商或監控工具的歷來資料。
穩定
過載的伺服器可能會迅速導致系統其他部分發生連鎖性故障。因此，請務必先讓伺服器穩定，再嘗試進行更重大的變更。
頻率限制
頻率限制可限制傳入要求的數量，以保護基礎架構。隨著伺服器效能下降，這項功能的重要性也越來越高：隨著回應時間增加，使用者往往會頻繁重新整理網頁，進而進一步增加伺服器負載。
修正
雖然拒絕要求的成本相對較低，但保護伺服器的最佳方式，是透過負載平衡器、反向 Proxy 或 CDN 等上游工具，處理頻率限制。
操作說明：
延伸閱讀：
HTTP 快取
尋找更積極快取內容的方法。如果資源可從 HTTP 快取 (無論是瀏覽器快取還是 CDN) 提供，就不需要從原始伺服器要求，進而減少伺服器負載。
Cache-Control、Expires 和 ETag 等 HTTP 標頭會指出 HTTP 快取機制應如何快取資源。檢查並修正這些標頭可改善快取功能。
雖然服務工作者也可以用於快取，但它們會使用獨立的快取，因此是適當 HTTP 快取的補充，而非替代方案。因此，在處理超載的伺服器時，應著重於改善 HTTP 快取。
診斷
執行 Lighthouse，並查看「運用有效率的快取政策來放送靜態素材資源」稽核項目，瞭解哪些資源的存留時間 (TTL) 介於短至中等。針對每個列出的資源，請考慮是否應增加 TTL。以下提供大致的規範：
- 靜態資源應以長 TTL (1 年) 快取。
- 動態資源應以短 TTL (3 小時) 快取。
修正
將 Cache-Control 標頭的 max-age 指令設為適當的秒數。
操作說明：
優雅降級
優雅降級是指暫時減少功能，以便減少系統的過多負載。這項概念可應用於多種不同的方式，例如提供靜態文字頁面而非功能齊全的應用程式、停用搜尋功能或減少搜尋結果數量，或是停用特定的昂貴或非必要功能。應著重於移除可安全且輕鬆移除，且對業務影響最小的功能。
改良
使用內容傳遞聯播網 (CDN)
您可以將提供靜態資產的負載從伺服器卸載到內容傳遞網路 (CDN)，藉此減少負載。
CDN 的主要功能是提供大量伺服器網路，讓使用者能快速取得內容，不過，大多數 CDN 也提供其他效能相關功能，例如壓縮、負載平衡和媒體最佳化。
設定 CDN
CDN 的優勢在於規模，因此自行營運 CDN 通常不太合理。基本 CDN 設定相當快速 (約 30 分鐘)，只需更新 DNS 記錄，將其指向 CDN。
最佳化 CDN 用量
診斷
執行 WebPageTest，找出未透過 CDN 提供 (但應透過 CDN 提供) 的資源。在結果頁面中，按一下「有效使用 CDN」上方的方塊，查看應透過 CDN 提供的資源清單。
修正
如果 CDN 未快取資源，請確認是否符合下列條件：
- 回應含有
Cache-Control: public標頭。 - 包含
Cache-Control: s-maxage、Cache-Control: max-age或Expires標頭。 - 包含
Content-Length、Content-Range或Transfer-Encoding header。
調度運算資源
請謹慎決定是否要調度運算資源。雖然運算資源經常需要擴充，但過早擴充可能會造成不必要的架構複雜度和財務成本。
診斷
如果第一個位元組時間 (TTFB) 偏高，可能表示伺服器的負載量已達上限。您可以在 Lighthouse 的縮短伺服器回應時間 (TTFB) 稽核中找到這項資訊。
如要進一步調查，請使用監控工具評估 CPU 用量。如果目前或預期的 CPU 使用率超過 80%，建議您增加伺服器。
修正
新增負載平衡器後，您就能將流量分配到多個伺服器。負載平衡器會位於伺服器集區前端，並將流量導向適當的伺服器。雲端服務供應商會提供專屬負載平衡器 (GCP、AWS、Azure)，您也可以使用 HAProxy 或 NGINX 自行設定。負載平衡器就位後，您就可以新增其他伺服器。
除了負載平衡，大多數雲端服務供應商也提供自動調度資源功能 (GCP、AWS、Azure)。自動調度資源功能會與負載平衡功能搭配運作，在特定時間內自動調度運算資源，以滿足需求。不過，自動調度資源並非萬靈丹，新執行個體上線需要時間，而且需要進行大量設定。由於自動調度資源功能會帶來額外的複雜性，因此建議您先考慮採用較簡單的負載平衡器設定。
啟用壓縮功能
文字資源應使用 gzip 或 brotli 進行壓縮。Gzip 可將這些資源的傳輸大小縮減約 70%。
診斷
使用 Lighthouse 的「啟用文字壓縮」稽核，找出應壓縮的資源。
修正
請更新伺服器設定，啟用壓縮功能。操作說明：
最佳化圖片和媒體
圖片是大多數網站檔案大小的主要組成部分，因此只要最佳化圖片，就能快速大幅縮減網站大小。
診斷
Lighthouse 提供多種稽核項目，可標示潛在的圖片最佳化項目。另一種做法是使用 DevTools 找出最大的圖片檔案，這些圖片很可能適合進行最佳化。
相關 Lighthouse 稽核：
Chrome 開發人員工具工作流程：
- 記錄網路活動
- 點選「Img」即可篩除非圖像資源
- 按一下「Size」欄，即可依圖片大小排序
修正
如果時間有限…
請專注於找出經常載入的大圖片，並使用 Squoosh 等工具手動最佳化圖片。主頁橫幅圖片通常是最佳化圖片的理想選擇。
注意事項：
- 大小：圖片大小不應超過必要的大小。
- 壓縮：一般來說，品質等級 80-85 對圖片品質的影響很小，但可縮減 30-40% 的檔案大小。
- 格式：使用 JPEG 儲存相片，而非 PNG；使用 MP4 儲存動畫內容，而非 GIF。
如果有更多時間…
如果圖片是網站的重要內容，建議您考慮設定圖片 CDN。圖片 CDN 專為圖片服務和最佳化而設計，可從原始伺服器卸載圖片服務。設定圖片 CDN 很簡單，但需要更新現有的圖片網址，使其指向圖片 CDN。
延伸閱讀：
壓縮 JS 和 CSS
壓縮會從 JavaScript 和 CSS 中移除不必要的字元。
診斷
使用 壓縮 CSS和 壓縮 JavaScript Lighthouse 稽核，找出需要壓縮的資源。
修正
如果時間有限，請專注於壓縮 JavaScript。大多數網站的 JavaScript 比 CSS 多，因此這項變更會帶來更顯著的影響。
監控
伺服器監控工具可提供伺服器效能相關資料收集、資訊主頁和快訊。這類工具可協助您預防及緩解日後的伺服器效能問題。
監控設定應盡可能簡單。過度收集資料和發出警示會產生成本：收集資料的範圍或頻率越大，收集和儲存資料的成本就越高；過度發出警示勢必會導致網頁遭到忽略。
警示應使用可持續且準確偵測問題的指標。伺服器回應時間 (延遲時間) 是這類情況下特別實用的指標，因為它可以找出各種問題，並直接與使用者體驗相關。以 CPU 使用率等較低層級指標發出警示雖然有助於補足其他方法的不足，但只能偵測到較少的問題。此外，您應根據尾端 (也就是第 95 或 99 百分位數) 觀察到的成效，而非平均值，發出快訊。否則，平均值很容易掩蓋不會影響所有使用者的相關問題。
修正
所有主要雲端服務供應商都提供專屬的監控工具 (GCP、AWS、Azure)。此外，Netdata 也是免費的開放原始碼替代方案。無論您選擇哪種工具，都必須在每部要監控的伺服器上安裝該工具的監控代理程式。完成後，請務必設定警示。
操作說明：