如何判定伺服器瓶頸、迅速修正瓶頸、改善伺服器效能，以及避免日後再次發生效能問題。
總覽
本指南將說明如何透過 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) 較短或中等的資源清單。請考量是否要提高各項資源的存留時間。概略準則如下：
- 靜態資源應以較長的存留時間 (1 年) 快取。
- 動態資源應以較短的存留時間 (3 小時) 快取。
修正
將 Cache-Control 標頭的 max-age 指令設為適當的秒數。
指示：
優雅降級
優雅降級是指暫時減少功能，以減輕系統過多負載的策略。這個概念可以透過多種方式應用，例如提供靜態文字頁面，而非功能完整的應用程式、停用搜尋功能或傳回較少搜尋結果，或停用某些高成本或非必要功能。重點應放在移除可安全且輕鬆移除的功能，同時盡可能減少對業務的影響。
改良
使用內容傳遞網路 (CDN)
您可以將靜態資產的提供作業從伺服器卸載至內容傳遞網路 (CDN)，藉此減輕負載。
CDN 的主要功能是透過靠近使用者的大型伺服器網路，快速向使用者提供內容。不過，大多數 CDN 也提供其他與效能相關的功能，例如壓縮、負載平衡和媒體最佳化。
設定 CDN
CDN 的優勢在於規模，因此自行營運 CDN 通常不具效益。基本 CDN 設定相當快速 (約 30 分鐘)，包括更新 DNS 記錄以指向 CDN。
最佳化 CDN 用量
診斷
執行 WebPageTest，找出未透過 CDN 提供 (但應該透過 CDN 提供) 的資源。在結果頁面中，按一下「Effective use of CDN」上方的方塊，即可查看應透過 CDN 提供的資源清單。
修正
如果 CDN 未快取資源，請確認是否符合下列條件：
- 回應含有
Cache-Control: public標頭。 - 回應含有
Cache-Control: s-maxage、Cache-Control: max-age或Expires標頭。 - 具有
Content-Length、Content-Range或Transfer-Encoding header。
調度運算資源
請務必謹慎決定是否要調度運算資源。雖然擴充運算資源通常是必要之舉，但過早擴充可能會導致架構不必要地複雜，並產生財務成本。
診斷
如果 Time To First Byte (TTFB) 偏高，可能表示伺服器已接近容量上限。您可以在 Lighthouse 的「縮短伺服器回應時間 (TTFB)」稽核中找到這項資訊。
如要進一步調查，請使用監控工具評估 CPU 使用率。如果目前或預期的 CPU 使用率超過 80%，建議您增加伺服器。
修正
新增負載平衡器後，即可將流量分配到多個伺服器。負載平衡器位於伺服器集區前方，會將流量轉送至適當的伺服器。雲端服務供應商會提供自己的負載平衡器 (GCP、AWS、Azure)，您也可以使用 HAProxy 或 NGINX 設定自己的負載平衡器。設定負載平衡器後，即可新增其他伺服器。
除了負載平衡，大多數雲端服務供應商也提供自動調度資源功能 (GCP、AWS、Azure)。自動調度資源功能會與負載平衡搭配運作，根據特定時間的需求，自動調高或調低運算資源。不過，自動調度資源並非萬能，新執行個體需要時間才能上線，而且需要大量設定。由於自動調度資源會增加複雜度，因此建議您先考慮採用較簡單的負載平衡器設定。
啟用壓縮功能
文字資源應使用 gzip 或 brotli 壓縮。Gzip 可將這些資源的傳輸大小縮減約 70%。
診斷
使用 Lighthouse 的「啟用文字壓縮」稽核功能，找出應壓縮的資源。
修正
更新伺服器設定，啟用壓縮功能。指示：
最佳化圖片和媒體
圖片是大多數網站檔案大小的主要來源，因此最佳化圖片可快速大幅縮減網站大小。
診斷
Lighthouse 提供多種稽核功能，可標記潛在的圖片最佳化項目。或者，您也可以使用開發人員工具找出最大的圖片檔，這些圖片可能很適合進行最佳化。
相關 Lighthouse 稽核：
Chrome 開發人員工具工作流程：
修正
如果時間有限…
請將時間花在找出經常載入的大型圖片，並使用 Squoosh 等工具手動最佳化。主頁橫幅通常是最佳化的理想選擇。
注意事項：
- 大小：圖片大小應適中。
- 壓縮：一般來說，品質等級設為 80 至 85 時，對圖片品質的影響最小，同時可將檔案大小縮減 30% 至 40%。
- 格式：相片請使用 JPEG 格式，而非 PNG；動畫內容請使用 MP4 格式，而非 GIF。
如果時間充裕…
如果網站上有大量圖片，建議設定圖片 CDN。圖片 CDN 專為提供及最佳化圖片而設計，可減輕原始伺服器的圖片提供負擔。設定圖片 CDN 很簡單，但需要更新現有圖片網址，指向圖片 CDN。
延伸閱讀：
壓縮 JS 和 CSS
壓縮功能會移除 JavaScript 和 CSS 中不必要的字元。
診斷
使用 Minify CSS 和 Minify JavaScript Lighthouse 稽核，找出需要壓縮的資源。
修正
如果時間有限，請著重於壓縮 JavaScript。大多數網站的 JavaScript 比 CSS 多，因此這項做法的效果更顯著。
監控
伺服器監控工具提供資料收集、資訊主頁和伺服器效能快訊。使用這些工具，有助於預防及緩解日後的伺服器效能問題。
監控設定應盡可能保持簡單。過度收集資料和發出快訊會產生費用：資料收集的範圍或頻率越大，收集和儲存的費用就越高；過度發出快訊必然會導致網頁遭到忽略。
警告應使用能持續準確偵測問題的指標。伺服器回應時間 (延遲時間) 是特別適合這項用途的指標：可找出各種問題，且與使用者體驗直接相關。根據 CPU 使用率等較低層級指標設定快訊，可做為實用的輔助工具，但只能偵測到一小部分問題。此外，快訊應根據尾端 (即第 95 或 99 個百分位數) 觀察到的成效，而非平均值。否則，平均值很容易掩蓋未影響所有使用者的問題。
修正
所有主要雲端服務供應商都提供自己的監控工具 (GCP、AWS、Azure)。此外，Netdata 也是絕佳的免費開放原始碼替代方案。無論選擇哪種工具，都必須在要監控的每部伺服器上安裝工具的監控代理程式。完成後，請務必設定快訊。
指示：