QCon上海2015 大流量Web系统的性能优化实践 许令波（君山）
2020-03-01 82浏览
- 1.大流量Web系统性能优化实践 君山 2015.10.15
- 2.2015-6-3
- 3.2015-6-3
- 4.关于我 • • • • 许令波(君山) 在阿里6年，做了4件还不错的事情 商品详情、店铺、图片空间TL 关注大流量web系统的架构和性能优化工作。
- 5.目录 • 这些年的挑战 • 我们走过的路 • 我们的经验 5
- 6.流量爆发增长 • 图片来自网上
- 7.系统还比较脆弱 • 图片来自网上
- 8.环境造就了技术 图片来自网上
- 9.搞不好就淹死了 图片来自网上
- 10.业务爆发增长 图片来自网上
- 11.只有在这里才能遇到 图片来自网上
- 12.遇到的挑战 • 流量爆发增长带来机器的成倍增加，系统必 须要能水平扩展 • 流量的峰值（秒杀），单商品或者用户维度 会出现热点，给cache带来瓶颈 • 大面积的攻击，如何区分正常流量防止误杀 • 复杂的业务逻辑给系统系统的耦合度和数据 的分类更加困难
- 13.我们走过的路 • 系统代码层面的优化 • 架构优化 • 链路优化
- 14.代码级优化
- 15.代码优化实践：模板引擎的热点 • • • • Velocity是动态解释性语言,执行效率较 差 页面复杂,反射调用非常多 发现模板渲染占用了60%以上的CPU时间。 整个页面输出比较大,平均在100KB左右。
- 16.代码优化实践：sketch模板引擎 • 将Velocity模板直接转成Java类去执行, 将 Velocity语法转成Java语法 • 将方法的反射调用转成直接Java原生方 法 调用 • 减少页面大小,删除空行等无效字符输 出 • 将页面中的字符转成字节输出减少编码 转 换
- 17.代码优化实践：class.forname热点 • Class.forname会导致线程block
- 18.代码优化实践：增加cache • 性能提升5%
- 19.more.. • 对象作为HashMap的key • web.xml配置版本信息可以减少启动时 annotation的扫描时间 • Logger创建没有使用static修饰符导致线程 阻塞 • 少用Thread.getStackTrace() • 正则运算尽量cache
- 20.架构优化 • 数据的动静分离 • 读写的分层校验
- 21.数据动静分离 • 系统的静态化是读系统性能优化的终极必 杀器 • 让用户的请求尽量不要经过Java系统 • 让静态数据放在离用户最近的地方 • 让动态数据尽可能的小
- 22.架构优化实践：读系统的静态化
- 23.架构优化实践:商品详情的静态化 • • • • 每天支持30+亿的PV 可以支持峰值100w的QPS 静态请求单机10000+（物理机） 动态请求单机1500+（16核）
- 24.读写数据的分层校验 看一下全球最大的秒杀系统如何实现
- 25.读写数据的分层校验 • 从一个普通的详情页面跳转过来
- 26.读写数据的分层校验 • 整个页面是cache在用户浏览器 • 如果强制刷新整个页面，也会请求到CDN • 实际有效请求只是“刷新抢宝”按钮
- 27.读写数据的分层校验 • 防止被秒杀器刷掉 • 通过答题分散用户的写请求，控制并发数
- 28.秒杀系统的执行逻辑
- 29.读写数据的分层校验总计 • 先做数据的动静分离 • 将99%的数据缓存在客户端浏览器 • 将动态请求的读数据cache在web端 • • • • 对读数据不做强一致性校验 对写数据进行基于时间的合理分片 对写请求做限流保护 对写数据进行强一致性校验
- 30.链路优化 • 链路优化的目标是整体提升用户访问体验 （低延时） • 从用户的浏览器/APP • 网关/CDN • 服务端(web系统/服务层/数据层)
- 31.用户访问链路 •http://www.webpagetest.org/video/compare.php?tests=140318_M5_7GV%2C140318_Z2 _7CJ&thumbSize=200&ival=100&end=full
- 32.用户访问链路 •http://www.webpagetest.org/video/compare.php?tests=140318_M5_7GV%2C140318_Z2 _7CJ&thumbSize=200&ival=100&end=full • 服务端响应时间只占整个请求路径上的很 小一部分 • PC上更重要的是优化首屏的加载 • 无线端更多的是优化中间的管道
- 33.无线端请求合并 • 无线环境下做请求合并的收益是比较大的，所以会将当前的两次请求 再服务端做ESI合并为一个请求。
- 34.数据量大小 • 无线环境下数据大小对性能影响比PC更加明显，PC从20k到80k增加了 100ms，而无线从20k到80k增加了700ms。所以无线控制页面大小对 性能影响很大
- 35.cache到CDN上 •直接从CDN上获取Cache后的数据性能很好，40k以下的页面只要600ms 左右。相当是直接回源一倍的性能
- 36.一些结论 •无线环境下一次网络请求要明显好于2次以上，减少网络请求次数对首 屏加载性能影响比较明显 •无线环境文件大小与PC环境下文件大小对性能影响的差异不同，无线环 境下数据大小对性能影响比PC更加明显，PC从20k到80k增加了100ms， 而无线从20k到80k增加了700ms。所以无线控制页面大小对性能影响很大 •CDN直接Cache性能提升很大，所以尽量数据Cache到CDN同样对无线是 有效的 •小数据情况下动态加速和直接回主站比较没有明显优势，加上当前动态 加速链路还在调优，所以当前无线数据直接回统一cache比较理想。待动 态加速更加成熟后再走CDN，当前统一Cache和CDN已经做到了动态切换， 所以往CDN也没有成本
- 37.more… • • • • 域名的收敛 DNS本地cache SPDY长连 图片本地cache • 合理的预加载机制
- 38.我们的经验 • • • • 知道短板 减少数据大小 数据分级 减少中间环节、增加预处理
- 39.发现短板 • • • • • 光速 网速 网络结构（交换机/网卡） TCP/IP 虚拟机（内存/cpu/io…） • 应用
- 40.减少数据大小 •HTML •图片 •JSON •Java对象 •请求数 40
- 41.数据分级 41
- 42.数据分级 • 首屏为先 • 重要信息为先 • 次要信息异步加载
- 43.减少中间环节
- 44.减少中间环节 • 减少中间代理 • 减少字符到字节的 转换 • 将变的转换为不变 的，增加预处理
- 45.回顾 1. 面临的挑战 – – 流量挑战 业务复杂度挑战 2. 我们走过的路 代码优化 架构优化 链路优化 3. 我们的经验 – – – – 知道短板 减少数据大小 数据分级 减少翻译、增加预处理
- 46.总结 1. 一定要做应用基线 – – – 性能基线（何时性能突然下降了？） 成本基线（去年双11用了多少台机器？） 链路基线（我们的系统发生了那些变化？） 2. 必须持续有人关注系统的性能 – – – 代码级（提升编码质量） 业务（改掉不合理的调用） 架构和链路级（改进架构） 3. 更通用和批量的解决问题 – – 整合系统之间的调研链路（合并部署） 提升整体机器使用率（弹性部署）
- 47.
- 48. 微博:@淘宝君山webchat:xulingbo0201邮箱:xulingbo0201@163.comhttp://xulingbo.net
