如何确定服务器的瓶颈、快速修复瓶颈、提高服务器性能以及防止衰退。
概览
本指南介绍如何通过 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 有各种审核,可以标记潜在的图像优化。或者,另一种策略是使用 DevTools 识别最大的图像文件 - 这些图像可能是优化的良好候选对象。
相关 Lighthouse 审核
Chrome DevTools 工作流程
修复
如果您时间有限…
将您的时间集中在识别大型且频繁加载的图像,并使用像 Squoosh 这样的工具手动优化它们。Hero 图像通常是优化的良好候选对象。
需要记住的事项
- 大小:图像应尽可能小。
- 压缩:一般来说,质量级别为 80-85 对图像质量的影响最小,同时可将文件大小减少 30-40%。
- 格式:照片请使用 JPEG 而不是 PNG;动画内容请使用 MP4 而不是 GIF。
如果您有更多时间…
如果图像占站点的大部分,请考虑设置图像 CDN。图像 CDN 旨在用于服务和优化图像,它们将从源服务器卸载图像服务。设置图像 CDN 很简单,但需要更新现有图像 URL 以指向图像 CDN。
延伸阅读
缩小 JS 和 CSS
缩小化会删除 JavaScript 和 CSS 中不必要的字符。
诊断
使用 缩小 CSS 和 缩小 JavaScript Lighthouse 审核来识别需要缩小化的资源。
修复
如果您时间有限,请专注于缩小 JavaScript。大多数站点的 JavaScript 比 CSS 多,因此这将更有效。
监控
服务器监控工具提供有关服务器性能的数据收集、仪表板和警报。它们的使用可以帮助预防和减轻未来的服务器性能问题。
监控设置应尽可能保持简单。过度的数据收集和警报有其成本:数据收集的范围或频率越大,收集和存储的成本就越高;过度的警报不可避免地导致页面被忽略。
警报应使用一致且准确地检测问题的指标。服务器响应时间(延迟)是一个特别适用于此目的的指标:它捕获了各种各样的问题,并与用户体验直接相关。基于较低级别指标(如 CPU 使用率)的警报可以作为有用的补充,但将捕获的问题子集较小。此外,警报应基于在尾部观察到的性能(换句话说,第 95 个或第 99 个百分位数),而不是平均值。否则,平均值很容易掩盖不影响所有用户的问题。
修复
所有主要的云服务提供商都提供他们自己的监控工具(GCP、AWS、Azure)。此外,Netdata 是一种出色的免费开源替代方案。无论您选择哪种工具,您都需要在要监控的每台服务器上安装该工具的监控代理。完成后,请务必设置警报。
说明