性能架构师看IT之家的性能问题及解法-阿里云开发者社区

开发者社区> 开发与运维> 正文

性能架构师看IT之家的性能问题及解法

简介: 这是一篇博主推荐给云栖社区的文章,转载自 IT科技范,讨论了一些不同的技术角度。2016.10.27网上出来一篇热文《IT之家公告:完成阿里云至百度云站点迁移工作》,不分析公关战,只从技术角度分析一下这件事情之我见。

【编者按】这是一篇博主推荐给云栖社区的文章,转载自 IT科技范 原文链接讨论了一些不同的技术角度。


2016.10.27网上出来一篇热文《IT之家公告:完成阿里云至百度云站点迁移工作》,作为一名朝阳吃瓜群众,兼前微软MSN.com(全球流量排名Top 3门户)、MSDN的性能架构师,不分析公关战,只从技术角度分析一下这件事情之我见,主要有以下几个问题,与用哪家云无关。

Blocking JS

出于本能,我很快就以最“庸俗”的测试方法,用HttpWatch(网页性能测试工具)看看IT之家(IThome.com)的主页构成结构waterfall,进行了PLT1(首次访问,不带cache和cookie)和PLT2(重复访问,带cache和cookie)测试。

主页没啥大问题,但看文章就明显卡了(测的时候是2016.10.28,根据IThome自己的说法应该已经在百度云上了),基本45秒~1分半白屏(网页不能操作,唯一可能就是JS blocking)。

例如打开《放个大招:如何高效完全地毁灭整个宇宙?》http://www.ithome.com/html/discovery/267809.htm,看一下HttpWatch的Waterfall chart:

c6e5a6c7dc08ecc363025c11ab4c13d1007168ac


足足1分45秒在等待loading一个广告Javascript:http://pagead2.googlesyndication.com/pagead/show_ads.js,重复了IE 9 和Chrome都是同样问题,只是等待时间从45秒到1分多钟不等。

这个JS是其上方的http://pos.baidu.com/yckm?di这个百度广告JS请求的,你真的确定要请求一个google的域名么?如果是跨国的,那就是被伟大的Great Firewall给墙了,唯一的结果就是等待这个请求超时返回,timeout时间可能就是那么长……

如果这个google域名在墙内,也要看链路用哪家运营商。所以这就是为啥在IT之家的公告之下有不少群众反映迁移后还是慢。

Load这个JS的百度请求源代码是这么写的,明显是synchronizationJavaScript(同步请求):

eea94eaa99d1191da0645a3ac09343dcefed07b8

就是最普通的<script src = “…”>的写法,大学生计算机第一课就教了。但踏上工作岗位进入像百度这样的大企业不该继续写这么幼稚的javascript loading方式啊,这个request不需要用synchronization JavaScript保证加载顺序的……

给大家科普一下:

1. 一个synchronization JavaScript加载(<script src = “…”>),其里面请求的JS加载多少时间,就会block整个浏览器多少时间,block的意思是网页根本不动,滚动条都没法动。

2. JS如果属于跨国被墙的域名,就会出现经典的“白屏”效果。可以很简单地尝试一个实验:写一个hello world网页,上面放一个来自于Google或Facebook的Javascript,例如<script src = “http://www.google.com/xxx.js”>,然后自己打开看看是否要很久都是白屏。

国外有些网站不知道这一经典陷阱,在国内打开时,发现各种加载慢或基本打不开,很多就是这个原因。

所以,IT之家和阿里云,你们貌似都被百度躺枪了……

解法很简单,就三行code,用Bing搜索一下non-blocking Javascript,不用我写了,一看就明白。

Cache(缓存)& CDN

IT之家有很多图片,但在重复加载时候,还是需要浪费请求去询问一下server要不要加载,返回304(已经cache缓存了)。细看一下每个图片的http header,基本都是设了超短的近乎无效的expiration header

9f0609e1e7aa4436b6486086cf36d6a9728690e3

45af2f458a5e61bb8515dacb39370331713f724d

来来回回几十个无意义的请求其实是会block住后面重要资源的加载,会让网页看起来一卡一卡有些慢。解法是设一个长一点的expiration header就可以了。

再谈一下CDN,很多人以为CDN cache一下图片CSS JS等静态资源就差不多了,其实不知CDN可以cache几乎任何东西,即使是一个动态资源请求,对于CDN来说也就是一个文件,照样可以cache。

以笔者之前的经历,MSN.com这个全球Top 3的门户网站,每日PV都是好几亿的,相比IT之家流量要大几百倍,而且是全球访问都保持PLT在1秒左右,在IT界几乎属于mission impossible(申明一下真不是做广告)。我们对其中一个流量超大的板块做performance tuning,将很多原先认为不能cache的动态资源|请求,都设了cache header放在CDN上面,就是timeout时间设短一点,例如1-15分钟(根据业务需求情况而定),甚至包括base页面即主请求main request(不可思议吧)。

结果是几乎没有什么request被传输到web server,基本全部被CDN以“静态资源cache”挡在门外,对于CDN简直是九牛一毛,web server的CPU轻松地我们都以为没开机呢,都在一位数左右,最终将76台服务器缩减到仅剩4台,而且4台根本CPU都在个位数,用4台的原因仅仅是用来做容灾……

这是为什么呢?很简单,静态资源(static request)如图片、CSS、JS对于web server的CPU消耗非常少,但是动态请求(dynamic request)就要走遍web server的全链路,对于资源消耗非常高,通常体现在CPU。然后不单是IIS连接池,就连很多要查询数据库的request都继续被送往SQL Server数据库(即使得到的response data是跟之前请求一模一样的),然后,然后SQL Server就跟着一起CPU high了。

所以其实很多情况下,像IT之家这种门户网站,单条内容更新频率其实并不高,可以说90%以上的内容都是可以被cache的,评论部分拆开请求就好了。在web + db的两层架构之间,也可以加一层cache,例如memcache或Redis或其它cache实现,这层么稍微花点钱。

其实,cost wise(价格方面),放CDN上面来cache大部分内容,要便宜很多很多,后台可以表示“轻松无压力”。

高可用&弹性扩展

接着上文继续说,如果省钱确实可以用一台虚拟机放web server。不过如果虚机挂了那就是真的挂了,业务挂了是最不划算的事情,一般至少2台虚机,在云上跨不同Availability Zone(可用区)以防止一个可用区(通常为一个物理机房)down掉。

其次,因为你要放2个以上web server互为主备,这时候就不推荐把SQL Server数据库都放在web server一起了(创业时可以这么干,成熟了就业务为先了)。数据库是核心资产,肯定要做主备,最好跨AZ甚至跨region,分开来放。试想911时候那架飞机,不单撞走了上千条人命,也撞走了好多公司,因为当时有不少人都是把数据库放办公室里的,以为楼永远不倒……然后,大家都放云上去了。

但是,NB的云服务商例如AWS和Azure,从来就会跟你说如果你自己不做备份,只用单实例,如果机器挂了他们不会对你的数据可靠性负责。因为如AWS般成熟的IT企业,其VP Werner Vogels都说过Everything Fails。业务可用性是要靠业主自己的架构去保障(例如备份、高可用),而不是物业去保障。难道你家客厅电视机坏了看不了世界杯还要去骂物业么?谁让你不在卧室也放个电视机咧(主备)?或者用笔记本看(高可用)?

关于高可用的架构,网上文章很多,我就不再赘述了。

然后,我要跟大家讲一个浅显易懂的道理:虚拟机 不等于 弹性计算。

云计算的初衷是让大家享受弹性计算,重点在“弹性”(Elastic)。很多人把这两个字给忘了,结果变成只有计算了,计算就变成只有虚拟机了。如果是这样,每个有Windows 7以上的人,因为可以安装HyperV来做虚拟机,就都有云计算啦!

弹性的根本,是用来解决你流量的高峰低谷时候用的资源扩容和缩容,即可以给你水平扩展(注意:此时要把数据库剥离开来别放web server一起哦)。AWS、Azure、阿里云都给你提供了Scaling Service,例如在阿里云叫Elastic Scaling Service(ESS),配置一下规则例如CPU到多少就扩容几台web server,挺简单的,事情不用想太复杂,成熟云服务商早都考虑好这点了,也是最最基本的服务。否则按照传统思维,难道真的都要升级配置,变成以前那种机器不行就加内存、换更贵的CPU,走上用小型机、大型机这种老路?那还要云计算干嘛。

总结

最后点个题,综上所述,这次“事件”从技术角度来看是个不大的问题,测试也发现实际上之前存在的卡慢现象在换了基础云之后依旧存在。这就尴尬了。要做好网站的优化是门长期功夫,靠堆硬件(指服务商的提供的性能)是不可取的,靠服务商来服务也是不够的。当然,对于借机PR的做法也不认同。(个人性格,不喜勿喷)

建议IT之家:(1)把Web和Database部署分离 (2)用ESS这种来扩容缩容 (3)做一下高可用。可能只需要1周时间。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章