如何确定服务器瓶颈、快速修复瓶颈、提高服务器性能以及防止性能下降。
概览
本指南介绍了如何分 4 个步骤修复过载的服务器:
评估
当流量使服务器过载时,以下一项或多项可能会成为瓶颈:CPU、网络、内存或磁盘 I/O。确定其中哪个是瓶颈,可以集中精力处理影响最大的缓解措施。
- CPU:应调查并修复始终高于 80% 的 CPU 使用率。当 CPU 使用率达到约 80-90% 时,服务器性能通常会下降;随着使用率接近 100%,服务器性能会越来越明显。处理单个请求的 CPU 利用率可以忽略不计,但是在流量高峰期处理的 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”按钮的箭头](https://web.developers.google.cn/static/articles/overloaded-server/image/arrow-pointing-the-effe-b5f163f623b97.jpg?authuser=5&hl=sk)
修复
如果 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 和 Minify JavaScript Lighthouse 审核来找出需要缩减的资源。
修复
如果您的时间有限,请专注于缩减 JavaScript 的大小。大多数网站包含的 JavaScript 多于 CSS,因此其影响会更大。
监控
服务器监控工具提供有关服务器性能的数据收集、信息中心和提醒。使用它们有助于预防和缓解未来的服务器性能问题。
监控设置应尽可能简单。过多的数据收集和提醒会产生相应的代价:数据收集的范围或频率越大,收集和存储的成本就越高;过多提醒不可避免地会导致网页被忽略。
提醒功能应使用始终如一地准确检测问题的指标。服务器响应时间(延迟时间)这个指标尤其适用于此情况:它可以发现各种问题,并与用户体验直接相关。基于 CPU 使用率等较低级别指标发出提醒非常有用,不过可以发现一小部分问题。此外,提醒应基于在尾部观察到的性能(即第 95 或第 99 百分位),而不是平均值。否则,平均值很容易被忽略并不会影响所有用户的问题。
修复
所有大型云服务提供商都提供自己的监控工具(GCP、AWS、Azure)。此外,Netdata 还是一个非常好的免费开源替代产品。无论您选择哪种工具,都需要在要监控的每台服务器上安装该工具的监控代理。完成后,请务必设置提醒。
操作说明: