• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
腾讯大讲堂18 让我们戴上有色眼镜--qzone前台架构的优化分享
 

腾讯大讲堂18 让我们戴上有色眼镜--qzone前台架构的优化分享

on

  • 2,861 views

 

Statistics

Views

Total Views
2,861
Views on SlideShare
2,771
Embed Views
90

Actions

Likes
2
Downloads
809
Comments
0

8 Embeds 90

http://news.cnblogs.com 63
http://www.cheungfei.com 11
http://www.leesum.com 6
http://woshao.com 5
http://feed.feedsky.com 2
http://home.cnblogs.com 1
http://www.tech-q.com 1
http://old.xianguo.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    腾讯大讲堂18 让我们戴上有色眼镜--qzone前台架构的优化分享 腾讯大讲堂18 让我们戴上有色眼镜--qzone前台架构的优化分享 Presentation Transcript

    • 让我们戴上 有色眼镜 ----Web 性能优化分享 QQ 空间产品中心 Stonehuang
    • Web 性能优化分享
      • 对于一个不断发展的 Web 应用,优化如同逆水行舟,不进则退。
    •  
    •  
    •  
    •  
    • 闭着眼睛也能优化
      • 页面内容实现动静分离
      • 页面 HTML 用 JS 生成
      • 全面推广 Ajax 技术
      • 前台对不同业务模块数据做 mash-up
      • 动态数据实现合并和静态化
      • 异步化
      • 各种各样看似合理的尝试和瞎忙活……
    • 我们早期的优化成果
      • 好像,大概,应该,也许,可能有些效果吧?
      • 数据……是很少滴!
      • 我们居然成功了,这要感谢我们前面有那么多的瓶颈,还有那么多公认的优化准则(银弹)可以套用
    • 优化平台期
      • 我们做了很多优化,打开速度也感觉快了很多,抱怨了少了一些,可是……
        • 哪个优化贡献最大?有多大影响?
        • 所有用户都快了吗?
        • 够快了吗?还能再快些吗?
        • 为什么有的时候还是感觉慢?
        • 为什么有些用户还是抱怨慢?
    • 优化平台期
      • 公认的优化手段几乎都用上了,还有新的银弹吗?
      • 有些优化手段代价很高,值得做吗?
      • 有些优化手段似乎相互矛盾,听谁的呢?
      • 为什么优化效果有反弹?
    • 带上有色眼镜
      • 转换不同的角度审视 web 应用
      • 用不同的监控手段监控 web 应用的不同方面
      • 为了满足自己的独特视角,发明自己独特的监控方式和工具
      • 想尽办法,发现自己真正的优化点
      • 每个优化有没效果,都需要有反馈
    • 早期的监控
    • 早期的监控
    • 早期的监控 自产自销的简单数据分析工具
    • 早期的监控 自产自销的简单数据分析工具
    • 持续进化的测速系统
    • 持续进化的测速系统
    • 持续进化的测速系统
    • 持续进化的测速系统
    • 持续进化的测速系统
    • 持续进化的测速系统
    • 持续进化的测速系统
    • 持续进化的测速系统 教育网 12 月份
    • 持续进化的测速系统 教育网 1 月份
    • 持续进化的测速系统
    • Gomez 数据采样分析工具
    • HttpWatch 分析工具
    • HttpWatch 分析工具
    • 限速工具
    • 限速工具
    • YSlow
    • YSlow
    • 自产自销的小工具
    • 自产自销的小工具
    • 透过有色眼镜看问题
      • 从静态化率波动我们看到了:
        • 每个新特性对数据产生的影响
        • 每次数据迁移带来的影响
        • 最迫切需要主动静态化的数据
        • 程序的 bug (相册无封面、个人信息转义符,甚至留言板 XSS )
        • 服务器压力不均造成的影响
        • 当前系统的趋势是在变好还是变坏
    • 透过有色眼镜看问题
      • 从时间点统计曲线我们看到了:
        • 每天 24 个时段的用户感受如何
        • 各个省份各个 ISP 当前情况如何
        • 用户花多少时间看到页面
        • 用户花多少时间才能和页面交互
        • 这些时间是怎么花掉的
        • 哪些用户花费的时间特别多
        • 我们应该从哪里下手继续优化
    • 透过有色眼镜看问题
      • 用各种第三方工具我们看到了
        • 页面打开过程一般会发生些什么事情
        • 某一个用户在打开某个页面时发生了什么
        • 什么时候浏览器在发呆
        • 哪些过程产生了堵塞,为什么堵塞
        • 有没有不必要的请求和不必要的流量
        • 如果网速很慢,会发生什么事情
        • 如果电脑很慢,会发生什么事情
        • 怎么让用户感觉好一点
    • 用有色眼镜看待优化手段
      • 我们做了许多些别人建议的事情
        • 合并图片,合并脚本,压缩代码,使用 Gzip ,,合并 CSS ,控制 cookie 膨胀,使用 CDN , SEO……
    • 用有色眼镜看待优化手段
      • 但即使是专家建议和公认的准则,我们也要进行自己的思考和审视
        • 拆分域名,尽可能并行下载?有更好的办法吗?
        • 页面标准化?用户价值在哪里?
        • 跨浏览器?非 IE 浏览器的用户有多少?使用 IE 的用户要付出的代价是什么?
        • 混淆压缩代码来减少流量?是否有更好的办法?
    • 只有不断创新,才能持续优化
      • 我们还进行了一些自己的思考和尝试
        • 网页使用本地持久存储:使用 User Data 和 Share Object
        • 动态数据 No Cache :尝试允许和控制动态数据 Cache ,并尝试让 CGI 放回 304
        • 全面改造 AJAX 为 JSON+AJAX
        • 动态页面分阶段渲染
        • DNS 解析错误的矫正
        • 优化指南
    • CheckList
      • * 资源检查(针对 html , js , swf , css ,图片等)
      • 是否新增加了文件请求?
      • 是否有 404 请求?
      • 新增加的文件请求响应中是否有 expirex 头(好头)?
      • 新增加的文件请求响应中是否有 etag 头(坏头)?
      • 新增加的文件请求是否支持 gzip 压缩?
      • 新增加的文件请求下载过程是否有 block?
      • 新增加的文件请求下载过程是否导致其他资源 block?
      • 新增加的文件请求能否延迟加载?
      • 是否减少了文件请求或者合并了文件请求?
      • 新增加的请求能否被浏览器缓存?
      • 新增加的请求是否适合进行长时间缓存?
      • 在 empty cache 和 full cache 两种情况下,是否有重复的文件请求?
      • 在 empty cache 和 full cache 两种情况下,是否有 abort 的文件请求?
      • 新增加的文件请求是否需要通过一个 301/302 跳转
      • (针对 imgcache )新增加的文件是否适合分散到新域名下?
    • CheckList
      • * Js 检查
      • 新增加的 js 请求能否合并到现有的 js 请求或者页面请求中?
      • 新增加的 js 请求是否在关键路径上 ?
      • 新增加的 js 请求能否放到 body 之后加载?能否延迟异步加载?
      • 新增加的 js 文件是否重写了大量已有 js 文件的代码?
      • Js 文件能否进行混淆和压缩?
      • 循环中的计算有没有能提出到循环外进行的?
      • 有没有大量连续的字符串连接操作(如有考虑用数组 join )
      • * CSS 检查
      • 新增加的 CSS 是否有相互 import ?
      • 新增加的 CSS 是否大量复写了原有 CSS 文件的大量规则?
      • 新增加的多个 CSS 能否合并?
      • CSS 能否直接写到 html 页面中 ( 可复用性高吗 ?) ?
      • 是否使用了 expression ?
      • 是否在 hover 样式中重新声明了背景图片(会导致重复请求)?
    • CheckList
      • * 限速检查
      • 是否进行过 netlimiter 限速测试?
      • 在限制 IE 下载进程为 2 个和 8 个两种情况下打开页面的速度是否有明显差异?
      • 是否进行过 cpukiller 限速测试?
      • * http 检查
      • DNS Lookup 次数:
      • Block 请求个数(请求的):
      • 关键路径上 Block 请求个数
      • *Cookie 检查
      • 是否创建了新的 cookie?
      • 是否创建了新的文件 cookie?
      • 是否创建了新的 qq.com 域名 cookie?
      • 能否用 user-data 或者 share object 代替 cookie ?
      • * 图片检查
      • 新增加的图片能否延迟到用户要看的时候再加载?
      • 新增加的图片是否用 innerHTML 方式填充到页面中的(可能导致重复请求)?
      • 新增加的图片是否需要进行预加载?
      • 新增加的图片能否合并到已有的图片中?
    • CheckList
      • * Html 检查
      • 是否使用了 iframe ?
      • Css 是否写在 head 中?
      • Script 是否(能否)写到页面最下面?
      • Html 文件能否进行混淆和压缩?
      • Inline 的 css 是否使用了了 expression, 是否在 hover 样式中重新声明了背景图片?
      • * flash 检查
      • Flash 是否使用了比较耗费 cpu 的渲染效果 ?
      • Flash 是否超过了 100k ?
      • Flash 是否需要下载额外的网络资源 ?
      • Flash 能否延迟加载 ?
      • * Ajax 检查
      • 页面能否分阶段渲染?
      • 页面能否边显示(或者交互)边渲染
      • 写操作是否用 post 方式提交
      • 读操作能否用 json 方式请求?
      • CGI 能否允许 cache ,能否支持 304 响应,能否支持 Gzip 压缩
    • Web 优化的与众不同
      • 对于一个永远 beta 版的 web 应用,每个版本都可能带来新的瓶颈
      • 只有不断随着产品而进化的监控手段,持续不断的监控,才能及时了解最新的瓶颈,发现最新的优化点。
    • 谢谢 The End