本月早些时候,大卫关于离开Mozilla的发自内心的帖子登上了Hacker News的头版。他原本就很繁忙的网站流量增加了800%,网站在压力下放慢了速度,最终出现故障。Request Metrics为David的博客监控性能和正常运行时间,我们的指标讲述了一个有趣的故事。这里是发生了什么,为什么,以及你可以做些什么来准备你的网站,以应对流量激增。
大卫的网站使用WordPress。它提供来自MySQL数据库的大部分内容,这是众所周知的性能限制。为了缓解这一问题,David使用Cloudflare缓存站点内容并减少服务器的负载。
CloudFlare通过控制DNS并在调用您的服务器之前通过其边缘网络路由请求来实现这一点。如果可能,Cloudflare将返回缓存的内容,而不需要调用您的服务器,这在请求量大幅增加时特别有用。它甚至对大多数网站都是免费的,这是相当棒的。
上午7点40分左右(当地时间),页面流量开始激增,系统从容不迫地进行了处理。页面加载的中位数在4-6秒是可以接受的。
到了早上7点50分,流量达到了技术的极限,每分钟大约有100次页面浏览量,用户体验很快就下降了。页面加载时间中值增长到30秒以上。由于无法满足这些请求,该网站在8点10分左右关闭,并保持了大约40分钟的离线状态。
如果你在这段时间内试图阅读他的帖子,你会有一次令人沮丧的经历。页面需要很长时间才能响应,如果您通过了,它会随着异步内容的加载和呈现而发生变化。我们可以将这些行为作为最大的内容油漆和累积布局偏移来衡量,它们都随着流量的增长而迅速下降。
很明显,这是很慢的。但是为什么呢?为什么它每分钟的浏览量不能超过100次呢?为什么云焰没有吸收流量?让我们更深入地挖掘这一页,看看发生了什么。
大卫的Mozilla帖子下面的性能报告显示了他登上HackerNews头版前后的48小时窗口。该页面不仅仅是HTML文档请求;它包括组成该页面的所有静态资产、JavaScript执行和动态请求。
在流量激增之前,页面的加载时间中值为4-6秒。这没问题,但是对于一个由Cloudflare提供的基本上是静态的站点,我会期望它快得多。
在中打开站点并在网络DevTools中检查文档请求为我们提供了线索。
服务器返回一个缓存控制标头,指出此内容不可缓存!CloudFlare遵守该指令,并将每个请求传递给服务器,如cf-cache-status:dynamic所示。
这样做的最终结果是,Cloudflare在其基础设施中引入了额外的跃点,但没有缓存任何内容,从而降低了站点的运行速度。
上面的页面性能报告还显示,每次加载页面时都会调用API端点/sidebar.php。此API的性能随流量峰值的下降情况类似,但在最好的情况下需要500ms才能做出响应。
在DevTools中检查此端点,它将返回我们所期望的HTML片段,即David博客的静态侧栏内容。并且它具有与主文档完全相同的缓存控制头问题。
通过将侧边栏呈现为异步不可缓存的请求,服务器被迫为每个阅读帖子的人提供至少2个涉及数据库的请求。这极大地限制了博客能够处理的请求数量。
您的网站与这个不同,但我们可以从这次绩效审计中吸取一些共同的想法。
该站点正在动态生成侧栏内容。它可能不需要是这样的。每个人的帖子都是相同的广告、流行标签和相关内容。
动态内容很慢。它很难缓存,而且通常必须异步获取。服务器只需做更多的工作来生成动态内容,而更多的工作总是较慢。
寻找动态内容,并确保与可以从缓存静态交付的内容相比,它的性能损失真的是值得的。
该站点设置为一度由Cloudflare缓存,但随着时间的推移,情况发生了变化。在WordPress插件或主机升级过程中的某个地方,缓存控制标头被更改,缓存被破坏。
软件系统是复杂和不断变化的。一定要时不时地测试一下,并确认每件事都在按其应有的方式工作。
简单地将Cloudflare添加到站点并不能解决性能问题,也不应该这样做。缓存和边缘网络令人惊叹,但您的站点需要进行配置才能正确使用它们。
性能不是你以后买的东西,也不是用来固定的。这是您在构建和运行系统时坚持的原则。像Request Metrics这样的性能监控工具可以帮助您集中精力并随着时间的推移提高性能。