技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统架构 --> 杨建:网站加速--实例分析篇

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

浏览:2454次  出处信息
--提升性能的同时为你节约10倍以上成本

    From: http://blog.sina.com.cn/iyangjian

    一,自选股分析

    二,NBA比赛分析

    三,播客分析

    四,开心网分析

    -----------------------------------------------------------------------------------------

    下面的图片都是在教育网访问的情况,我故意放大了某些缺陷,这样可以很好的模拟没有部署服务的地区对用户体验的影响。我只能针对我熟悉和了解的项目进行分析,另外还有我们经常访问的网站也会被拿来做素材分析。我们老大也说问题暴露出来,能推动解决的话也很好,大家别拍我。

    一,自选股分析

    

    某天我终于在教育网部署了一台行情服务,兴致冲冲的回家一试,貌似没啥变化,该慢还慢。打开页面过程持续了几十秒,然后终于露出了行情,我再电击每个组合的时候就出现了上面的一幕。看了下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=completeHTTP/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

    ----------------------------------------------------------------------------------------

    

    如果不是这几个资源的引用,这个页面的速度将非常快。

    

    这里引用了某些未在教育网部署的服务,导致半天出不了数据。

    

    由于引入了mark.sina.com.cn的数据导致整个页面卡在那里。引用别人数据的时候你了解过他们是怎么分布自己服务的吗?可能稍有不慎拖垮整个页面。

    
二,NBA比赛分析

    

    这里的js真的有必要每次都发起请求吗?连续请求3同域个资源,为什么不维持下长连接?

    

    这些图片的304响应为什么都在秒级以上?

    三,播客分析

    

    这些图片和视频由于解析错误,教育网用户被解析到广州服务器组,导致不可访问。

    四,开心网分析

    打开开心网,看到最多的就是人物图片,我就仅仅针对图片进行下分析:

    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这样的zerocopy系统调用,我觉得都浪费.同时还要保证图片更新立刻被感应到。  

    其他方面还有很多可以改进的,想让他们的页面响应速度上一个等级,节约更多带宽和服务器资源并非难事。

    

建议继续学习:

  1. 杨建:网站加速--服务器编写篇(上)    (阅读:3008)
  2. 杨建:网站加速--服务器编写篇 (下)    (阅读:2936)
  3. 杨建:网站加速--系统架构篇    (阅读:2913)
  4. 杨建:网站加速--Cache为王篇    (阅读:2866)
  5. 杨建:网站加速--内容简介    (阅读:2401)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1