BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

如何应对美国春晚“超级碗”带来的海量访问请求?

| 作者 郑柯 关注 3 他的粉丝 发布于 2013年2月8日. 估计阅读时间: 7 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

美国时间2013年2月4日,美国人民的春晚——美国橄榄球联盟(NFL)第47届“超级碗(Super Bowl)”总决赛——在新奥尔良穹顶体育场上演。“超级碗”有三个最吸引人之处:精彩的比赛、中场表演、比赛中插播的广告。

本届超级碗峰值家庭收视率达到71%,因此是广告主的必争之地,平均价格达到每30秒400万美元。诸多广告中,很多都号召观众去网站互动,因此导致众多网站不堪重负。

Yottaa是一家专门提供网站优化服务的公司,据他们监控,共有13家网站在本次事件中被不同程度拖垮。以可口可乐为例,其网站的加载时间达到62秒。SodaStream、Calvin Klein、Axe、Got Milk?以及其他电影和汽车站点亦受影响中枪。

那么如何避免类似情况呢?Yottaa提供了4点建议:

  • 减少网页上的元素数量的大小,创建更小、更轻量级的页面,以保证页面加载更快
  • 使用网站性能监控,以全天候发现任何网站可能发生的问题
  • 使用CDN,从地理位置上离你遍布世界各地的用户更近,减少网站的大部分流量
  • 根据预测的流量执行实时负载测试,要度量你的网站在高负载下的实际表现,这是唯一的方式。

个人开发者Michael Hamrah也在自己的博客上撰写了一篇文章《如何应对“超级碗”这样的高峰流量》,文中也给出了一些建议:

  • 做出假设。

要敢于假设你的流量模式。这有助于你针对自己的特定情形进行优化。很多面向大众的网站,其访问都是匿名的,特别是像超级碗这样的流量高峰。因为你可以针对所有的匿名用户提供完全一样的内容,你可以让他们访问完全一样的静态页面。缓存控制决定了内容多久仍有效,并可使用HTTP加速器和CDN进行分发。不用针对每个人都做优化,将用户分类,为大多数优化。把页面上的缓存规则设为1分钟,这都可以降低应用负担,释放有价值的资源。匿名用户可以更快下载静态缓存内容,动态用户将可以更快地访问服务器。

你也可以针对高度动态的内容创建特定的渲染管道,供匿名和已知用户使用。如果你能早些识别匿名用户,就可以避免代价高昂的数据库查询、外部API调用或是页面渲染。

  • 理解HTTP

HTTP是web的基础,更深入地理解HTTP,你就更好地利用工具优化页面。要特别注意Http报头的缓存设置,这让你可以利用Varnish和CDN这样的web加速器。使用不同报头针对匿名和已知用户,你可以对各自访问的内容有更精细的控制。过期报头决定内容的新旧程度。最糟糕的做法,就是把缓存报头设置为不公开静态内容,阻止浏览器缓存本地内容。

  • 使用Varnish和ESI

Varnish是一个HTTP加速器,它可以缓存网站产生的动态内容。Web框架常常有自己的内容缓存特性,但是Varnish让你可以完全越过应用栈,提供更快的响应时间。你可以向更多连接发送已渲染好的动态页面,就像发送内存中的静态页面一样。

Edge Side Includes简称ESI,是将静态和动态内容混合在一起。如果一个页面对所有人来说有90%是接近的,那么你可以在Varnish中缓存90%,然后让应用服务器发送其他10%。ESI刚刚在web框架中出现,在Rails 4中,它会占据更重要的地位。

  • 使用CDN和多个数据中心

如果你在多个数据中心中运行Varnish服务器,这就等于创建了自己的CDN。数据库和内容也许存放在东海岸,但如果你在西海岸运行一台Varnish服务器,你在旧金山的用户就会得到更快的响应时间,你也可以减少一个到应用服务器的链接。即使Varnish必须通过东海岸的ESI发送10%动态内容,它也可以利用数据中心之间更快的连接。

  • 使用自动扩展组或警告

自动扩展组是AWS的出色功能,尤其达到某个阈值最大值的时候。如果你没有使用AWS,优秀监控工具能帮你采取行动。如果你在设计应用时考虑到了自动扩展,在内部通信使用负载均衡器,也是不错的选择。

  • 压缩并序列化数据

如果开启压缩,页面大小就能大幅降低。Web流量主要是文本,易于压缩。别忘了内部通信也可以压缩。在当今这个API驱动的世界里,诸如协议缓存这样的高效序列化协议可以大幅降低网络流量。很多RPC工具支持某种形式的序列化优化。SOAP是二十一世纪早期的热门方法,但从速度角度考虑,XML是最差的数据序列化方法。压缩内容能在缓存内保存更多东西,同时降低网络I/O。

  • 关闭某些特性

在高流量时刻,关闭表现不正常的特性是解决问题的最快方式。

  • 非阻塞的I/O

异步编程充满挑战,也许是扩展性的最后一道关隘。有时,网站服务器崩溃了,却看不出达到任何阈值。也许你曾看到一个缓慢的请求,但是内存、CPU和网络的访问指标都很正常。这种情况常常是由于某种形式的I/O线程被阻塞然后等待造成的。被阻塞的线程让其他事情都停下来。基于异步的框架,比如node.js,将异步编程放在前端,让它们处理更多并发请求。异步编程还为基于队列的架构铺平道路。如果每个请求都通过队列处理,这有助于缓解流量高峰。队列大小会决定你需要多少个队列的worker。异步也许不太好理解,但这是处理扩展的重要方式。

Michael的最后一个建议是总结性的:

  • 以扩展的方式思考

在高负载环境中处理问题时,一切都要考虑在内。针对几千个用户没有问题的方法,要是用来对付几百万用户,可能就失去控制了。即使是最小的问题,也会以指数级增长,变得不可收拾。

扩展不仅仅是要想到用来对付负载的工具,而是要决定你的应用如何表现。最重要的事情,是要判定页面内容对于用户的新旧程度。对于每个用户都提供秒级的更新,或是针对匿名用户提供分钟级的更新,二者的决策完全不同。在应对数百万并发请求时,一个会带来很多工程上的复杂度,另一个则可以快速解决。

看到美国人民的春晚导致的网站崩溃之后,你认为会在中国人民的春晚播放时发生吗?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

说实话,对于性能工程(Performance Engineering)关注度还远远不够! by 高 翌翔

在web应用程序的实际开发中,一些程序员只关注功能实现,即先做出来再说,
至于10人、100人、1,000人……100,000人同时访问某功能时会怎么样?
答案通常是“不知道”、“不清楚”、或是“到时候再说”!

现在时候到了,答案已经揭晓:网站不堪重负崩溃了。
你猜那些程序员会说些什么?
不难想象,要么是早已跳槽走人、销声匿迹,要么是怨天尤人、不知所措。

那些程序员不是别人,也许就是俺自己。

不过,问出来了就要解决,文中给出了一些不错的策略、方法、及建议,但让人感觉过于零散,不成体系。

最近正巧在关注此类问题,其实这些问题都属于“性能工程(Performance Engineering)”的领域。
简言之,性能工程贯穿软件开发生命周期始终,从需求说明书中的非功能需求,一直到运维阶段的实时性能监控及预测。
但是,对于性能工程关注度还远远不够,甚至一无所知!

顺便回答一下最后抛出的问题,看到美国人民的春晚导致的网站崩溃之后,你认为会在中国人民的春晚播放时发生吗?
答:基本不会出问题。分析如下:
1 从访问量来看,通过网络观看春晚的观众不会太多,因为大多数观众会选择与家人一起通过电视观看春晚;
2 从内容类型来看,主要是流媒体播放,而当今的流媒体技术已比较成熟,问题不大(否则,视频网站还搞神马);
3 从技术来看,主要靠CDN(内容分发网络),这时候基本上就是靠蓝汛了,毕竟蓝汛在中国是CDN的老大。
(个人意见,仅供参考。)

Re: 说实话,对于性能工程(Performance Engineering)关注度还远远不够! by Mor Andjia

怎么不提12306

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT