杨建：网站加速--实例分析篇

超、凢脫俗 2022-05-26 05:41 169阅读 0赞

转自 [http://blog.sina.com.cn/s/blog\_466c66400100bkis.html][http_blog.sina.com.cn_s_blog_466c66400100bkis.html]

\--提升性能的同时为你节约10倍以上成本  
From: http://blog.sina.com.cn/iyangjian  
  
一，自选股分析  
二，NBA比赛分析  
三，播客分析  
四，开心网分析  
\-----------------------------------------------------------------------------------------  
  
下面的图片都是在教育网访问的情况，我故意放大了某些缺陷，这样可以很好的模拟没有部署服务的地区对用户体验的影响。我只能针对我熟悉和了解的项目进行分析，另外还有我们经常访问的网站也会被拿来做素材分析。我们老大也说问题暴露出来，能推动解决的话也很好，大家别拍我。  
  
**一，自选股分析**  
  
![1348357297_4735.jpg][]  
某天我终于在教育网部署了一台行情服务，兴致冲冲的回家一试，貌似没啥变化，该慢还慢。打开页面过程持续了几十秒，然后终于露出了行情，我再电击每个组合的时候就出现了上面的一幕。看了下firebug，最慢资源排名前三依次为：高效计数服务，secure-cn统计服务，动态池服务。  
  
高效计数服务是早期我参与的项目，那时候资源有限，全部部署在了网通。  
secure-cn统计服务: 这个服务不慢是不正常的，到处都嵌，还不能不嵌。  
动态池数据库很牛，但在偏远地区也鞭长莫及。这个缺点比较典型:  
一，没有在教育网部署。  
二，没有保持长连接。  
三，没有使用cahce  
四，没有使用压缩  
五，长达2.46K的http 请求header，捎带大量cookie，见下面。  
  
解决方法：我分析了下，下面这个数据变化很慢的，主要放一些市盈率和用户股票列表。市盈率可以通过去年的每股收益来计算，以年计，可以变通一下。用户股票列表我也好几个月没更新了,大家并不是总更新。所以这部分数据是可以被设置一个很长的cache的，如果用户更新了股票列表，我们也只需要在maxage版本号上加1就ok了。另外，用户点了一个组合，接看来也都要看几个别的组合，没有维持长连接显然不合理的。在没有部点的idc，压缩就能明显的提升响应速度，这里就没考虑。那个cookie太长点了吧，真的用的了那么长吗。  
  
  
http://vip.stock.finance.sina.com.cn/portfolio/stock.php?rn=1228707043897&pid=1245111&type=complete  
\----------------------------------------------------------------------------------------  
GET /portfolio/stock.php?rn=1228707043897&pid=1245111&type=complete HTTP/1.1  
Host: vip.stock.finance.sina.com.cn  
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,\*/\*;q=0.8  
Accept-Language: zh-cn,zh;q=0.5  
Accept-Encoding: gzip,deflate  
Accept-Charset: gb2312,utf-8;q=0.7,\*;q=0.7  
Keep-Alive: 300  
Connection: keep-alive  
Cookie: CurrentBar=attend; CurrentTab=state; CombinationSelected=154148; CommisionCookie=0; StampCookie=0; FeeCookie=0; BX=7t1oh653u6qvb&b=3&s=4k; SINA\_NEWS\_CUSTOMIZE\_city=%u5317%u4EAC; userId=C7DHwoAi-ryCr69CGgyc3czekbyphdy5hcxQNhFcN6zCNe; FINA\_VISITED\_S=sh601988|-y?L,sh580989|W\*JTP1,sh601988|-y?L,sh601988|-y?L,sh580989|W\*JTP1,sh601988|-y?L,sh601988|-y?L,sh601988|-y?L,sh580989|W\*JTP1; Iask2\_visitID=10.217.21.44.177601199668733612; UNIPROCT=342-0-0:2; hold\_sinabar\_name=iyangjian2005997; UNIPROPATH=2:iyangjian2005997:0::1:|\*|202.112.174.100.97191204115419966|pid:342-0-0-0-0|classad.sr/|st:25.906|et:1204118703312||hp:unkown|lb:1|\*|; SINAPUID=10.217.21.64.250871201592749264; vjuids=-5600fbe60.117402dbc5e.0.42a2debdf9f46; VISITED\_FANCHAN\_SINA\_ZHANGYQ=SINA\_BEIJING; S\_WC\_USRTOK=SFyLe9; stat=0806201608589720436533; MY\_STOCK\_LIST\_2=sh600602; visited\_futures=SI%7CCL%7CGC%7CCAD%7CTRB%7Cau0812%7CCC%7CPBD%7CCF907%7CNID; SINA\_FINANCE=iyangjian2005997%3A1181509184%3A2; visited\_funds=000011%7Csh000011%7C159902%7C160314%7C377016%7C270005%7C202009; SINA\_FINANCE\_SELECT\_TYPE=stock; vjuid=-12b4fad5c.1174d78e8a5.0.6099c257a27eb; vjlast=1199616063; vjlast=1199616063,1228706963,10; sina\_sort\_default=117; SHOW\_TIP\_BOX=1; FINA\_V\_S\_2=sz000609,sz000723,sh000001,sz002242,sz002274,sz000049,sz002272,sh600432,sh601186,sh601390,sh600036,sz000625; hk\_visited\_stocks=HSI%7C04338%7CHSCEI%7CHSCCI; visited\_cfunds=050007%7Csz161010; \_\_utma=269849203.390390911.1226996335.1226996335.1226996335.1; \_\_utmz=269849203.1226996335.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); SINAGLOBAL=202.112.174.100.224381203683121713; Apache=202.112.174.100.771641228691763829; SessionID=e9bc0f217040ae10439d85f422f3187a; SINA\_PORTFOLIO=sz000514%2Csh600729%2Csh600438%2Csh600528%2Csh600678%2Csh600877%2Csh600039%2Csh601005%2Csh600875%2Csz001696%2Csz000628%2Csh600116  
Cache-Control: max-age=0  
  
HTTP/1.x 200 OK  
Date: Mon, 08 Dec 2008 03:32:52 GMT  
Server: Apache  
Cache-Control: no-cache  
Expires: Mon, 08 Dec 2008 03:34:52 GMT  
Connection: close  
Transfer-Encoding: chunked  
Content-Type: text/html; charset=GBK  
\----------------------------------------------------------------------------------------  
  
![1348357321_2941.jpg][]  
如果不是这几个资源的引用，这个页面的速度将非常快。  
  
![1348357346_1407.jpg][]  
这里引用了某些未在教育网部署的服务，导致半天出不了数据。  
  
  
![1348357366_4657.jpg][]  
由于引入了mark.sina.com.cn的数据导致整个页面卡在那里。引用别人数据的时候你了解过他们是怎么分布自己服务的吗？可能稍有不慎拖垮整个页面。  
  
  
**二，NBA比赛分析**  
  
![1348357388_4793.jpg][]  
这里的js真的有必要每次都发起请求吗？连续请求３同域个资源，为什么不维持下长连接？  
  
  
![1348357407_8255.jpg][]  
这些图片的３０４响应为什么都在秒级以上？  
  
**三，播客分析**  
  
![1348357426_3466.jpg][]  
  
这些图片和视频由于解析错误，教育网用户被解析到广州服务器组，导致不可访问。  
  
  
**四，开心网分析**  
  
打开开心网，看到最多的就是人物图片，我就仅仅针对图片进行下分析：  
  
1,浏览一个新人的页面,大概要下载30~40张小图片。使用单一的pic.kaixin001.com域名，不能提高并发，可以考虑多域名取模。  
2,图片请求带了cookie，上行带宽浪费点无所谓，但是会影响响应速度和用户体验。  
3, /logo/10/51/50\_105146\_1.jpg ,他们设置了一个比较大的maxage，通过改名来实现更新大可不必，我用我的方法更好。  
4,每次点刷新页面，都会重新加载很多图片，虽然很多是304，我觉得绝大部分就不应该发这个请求。  
5,他用的是ChinaCache的CDN，Server: nginx，我不知道ChinaCache对这个server修改到什么程度。统计发现这个人物小图片大都在2k左右。很多才1k多。没有必要把他们当作图片处理。尽量不产生磁盘i/o,包括fstat这样的系统调用，甚至sendfile这样的zero copy系统调用，我觉得都浪费. 同时还要保证图片更新立刻被感应到。    
  
其他方面还有很多可以改进的，想让他们的页面响应速度上一个等级，节约更多带宽和服务器资源并非难事。

[http_blog.sina.com.cn_s_blog_466c66400100bkis.html]: http://blog.sina.com.cn/s/blog_466c66400100bkis.html
[1348357297_4735.jpg]: https://img-my.csdn.net/uploads/201209/23/1348357297_4735.jpg
[1348357321_2941.jpg]: https://img-my.csdn.net/uploads/201209/23/1348357321_2941.jpg
[1348357346_1407.jpg]: https://img-my.csdn.net/uploads/201209/23/1348357346_1407.jpg
[1348357366_4657.jpg]: https://img-my.csdn.net/uploads/201209/23/1348357366_4657.jpg
[1348357388_4793.jpg]: https://img-my.csdn.net/uploads/201209/23/1348357388_4793.jpg
[1348357407_8255.jpg]: https://img-my.csdn.net/uploads/201209/23/1348357407_8255.jpg
[1348357426_3466.jpg]: https://img-my.csdn.net/uploads/201209/23/1348357426_3466.jpg