QQ空间前台架构的优化分享.pptVIP

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? 是否创建了新的域名cookie? 能否用user-data或者share object代替cookie？ * 图片检查 新增加的图片能否延迟到用户要看的时候再加载？ 新增加的图片是否用innerHTML方式填充到页面中的（可能导致重复请求）？ 新增加的图片是否需要进行预加载？ 新增加的图片能否合并到已有的图片中？ Web优化的与众不同 对于一个永远beta版的web应用，每个版本都可能带来新的瓶颈 只有不断随着产品而进化的监控手段，持续不断的监控，才能及时了解最新的瓶颈，发现最新的优