如何确定服务器的瓶颈、快速修复瓶颈、提高服务器性能并防止回归。
概览
本指南将通过 4 个步骤向您展示如何修复服务器过载问题：
评估
当流量使服务器过载时，以下一项或多项可能会成为瓶颈：CPU、网络、内存或磁盘 I/O。确定其中哪一个是瓶颈，以便将精力集中在最有效的缓解措施上。
- CPU：如果 CPU 使用率持续超过 80%，则应进行调查并修复。当 CPU 使用率达到约 80-90% 时，服务器性能通常会下降，并且随着使用率接近 100%，性能下降会更加明显。处理单个请求的 CPU 利用率可以忽略不计，但在流量高峰期间，以这种规模处理请求有时可能会使服务器不堪重负。将服务分流到其他基础架构、减少高开销操作以及限制请求数量，都可以降低 CPU 利用率。
- 网络：在流量高峰期，满足用户请求所需的网络吞吐量可能会超出容量。某些网站可能还会达到累计数据传输上限，具体取决于托管服务提供商。减少与服务器之间传输的数据的大小和数量，即可消除此瓶颈。
- 内存：当系统内存不足时，数据必须卸载到磁盘进行存储。磁盘访问速度明显慢于内存，这可能会拖慢整个应用。如果内存完全耗尽，可能会导致内存不足 (OOM) 错误。调整内存分配、修复内存泄漏和升级内存可以消除此瓶颈。
- 磁盘 I/O：从磁盘读取数据或向磁盘写入数据的速率受磁盘本身限制。如果磁盘 I/O 是瓶颈，增加内存中缓存的数据量可以缓解此问题（代价是内存利用率提高）。如果此方法不起作用，则可能需要升级磁盘。
本指南中的技术侧重于解决 CPU 和网络瓶颈。对于大多数网站，CPU 和网络将是流量高峰期间最相关的瓶颈。
在受影响的服务器上运行 top 是调查瓶颈的良好起点。如果可以，请使用托管服务提供商或监控工具提供的历史数据来补充这些数据。
稳定
服务器过载可能会很快导致系统其他部分发生级联故障。因此，在尝试进行更重大的更改之前，请务必先稳定服务器。
速率限制
速率限制通过限制传入请求的数量来保护基础设施。随着服务器性能下降，这一点变得越来越重要：随着响应时间增加，用户往往会频繁刷新页面，从而进一步增加服务器负载。
修复
虽然拒绝请求的开销相对较低，但保护服务器的最佳方法是在服务器上游的某个位置（例如，通过负载均衡器、反向代理或 CDN）处理速率限制。
说明：
补充阅读材料：
HTTP 缓存
寻找更积极地缓存内容的方法。如果资源可以从 HTTP 缓存（无论是浏览器缓存还是 CDN）提供，则无需从源服务器请求，从而减少了服务器负载。
Cache-Control、Expires 和 ETag 等 HTTP 标头指示 HTTP 缓存应如何缓存资源。审核并修正这些标头可改进缓存。
虽然 Service Worker 也可用于缓存，但它们使用的是单独的缓存，是对适当 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 提供了各种审核，可标记潜在的图片优化。或者，另一种策略是使用开发者工具找出最大的图片文件，这些图片很可能适合进行优化。
相关的 Lighthouse 审核：
Chrome 开发者工具工作流：
修复
如果时间有限…
将时间集中在识别大型和频繁加载的图片上，并使用 Squoosh 等工具手动优化这些图片。主打图片通常是优化的理想对象。
注意事项：
- 大小：图片不应超出必要的大小。
- 压缩：一般来说，80-85 的质量级别对图片质量的影响微乎其微，同时可将文件大小缩减 30-40%。
- 格式：照片使用 JPEG 格式，而非 PNG 格式；动画内容使用 MP4 格式，而非 GIF 格式。
如果时间充足…
如果图片在您的网站中占很大比例，不妨考虑设置图片 CDN。图片 CDN 专为提供和优化图片而设计，可分担源服务器的图片传送工作。设置图片 CDN 非常简单，但需要更新现有图片网址，使其指向图片 CDN。
补充阅读材料：
缩减 JS 和 CSS 的大小
缩减大小会从 JavaScript 和 CSS 中移除不必要的字符。
诊断
使用 Minify CSS（缩减 CSS 的大小）和 Minify JavaScript（缩减 JavaScript 的大小）Lighthouse 审核来找出需要缩减大小的资源。
修复
如果时间有限，请专注于缩减 JavaScript 的大小。大多数网站的 JavaScript 比 CSS 多，因此这会产生更大的影响。
监控
服务器监控工具提供有关服务器性能的数据收集、信息中心和提醒。使用这些工具可以帮助预防和缓解未来的服务器性能问题。
监控设置应尽可能简单。过度的数据收集和提醒会带来成本：数据收集的范围或频率越大，收集和存储的成本就越高；过度提醒不可避免地会导致页面被忽略。
提醒应使用能够一致且准确地检测问题的指标。服务器响应时间（延迟时间）是一个非常适合用于此目的的指标：它能捕获各种各样的问题，并且与用户体验直接相关。基于 CPU 使用率等较低级别指标的提醒可以作为有用的补充，但只能捕获一小部分问题。此外，提醒应基于在尾部（即第 95 或第 99 百分位）观察到的性能，而不是平均值。否则，平均值很容易掩盖不会影响所有用户的问题。
修复
所有主要云服务提供商都提供自己的监控工具（GCP、AWS、Azure）。此外，Netdata 也是一个出色的免费开源替代方案。无论选择哪种工具，您都需要在要监控的每台服务器上安装该工具的监控代理。完成后，请务必设置提醒。
说明：