Weibo lamp improvements
•
42 gefällt mir•17,435 views
This is my one year work summary at weibo, we get more than 200% performance improvement in the last year, this ppt introduced how we did that.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie Weibo lamp improvements
Ähnlich wie Weibo lamp improvements (20)
Weibo lamp improvements
- 2. 微博示意图 2
- 3. 最初的微博 l Apache Prefork l PHP-5.2 + APC l Swift(Simplified Kohana) l Smarty l BigPipe 3
- 4. 最初的微博 l 日访问量巨大, 在业务高速增长期, 架构一直没变 l 响应时间越来越慢 l 用户效率, 服务成本. l 代码量庞大, 只做加法不敢做减法 l 开发成本大, 开发周期长 l 开发效率 l 工作方向 l 性能优化 l 结构优化 4
- 5. 内容 l 性能优化 l 框架优化 - Yaf l 配置优化 - Weibo l 模板优化 - 弃用Smarty l 并行化 - CBigpipe l 结构优化 l PL服务化 – Yar l 进行中的工作 l 接下来 5
- 6. Yaf – Yet Another framework l Yaf l PHP社区第一个C语言扩展框架, 最快的PHP框架 l 兼容PSR0的自动加载 l 基于命名空间的文件目录组织 l 自带高性能的PHP模板引擎 l 已开源 6
- 7. Weibo Extension l Weibo Ext l Weibo_Conf 1. 在Apache启动的时候Parse 2. Fork的时候利用COW, 避免共享内存 3. Lookup只需要一个zval的复制(时间复杂度,空间复杂度 O(1)) l Weibo_Util 1. 运算密集型/PHP脚本无法实现的功能 2. 业务无关性 3. ID encode, At, Link, Topic … 7
- 8. PHP Templates l 模板的优化 l Smarty太过庞大 l 不兼容的自动加载规则 l 编译后的模板代码臃肿,低效 l PHP本身就是一个很好的模板语言 l 模板自动转换工具 8
- 9. Apache Optimize l Apache配置调优 l 避免多余的配置 l 目录结构优化 l 梳理Rewrite规则, 去除无用分支 l 统一的国际化 l gettext全面应用 9
- 10. 性能优化 10 l 响应时间下降 44% l 吞吐提升 78% l CPU利用率下降 l 内存占用率下降
- 11. 业务解耦 l 代码过于繁多, 只做加法不做减法 l 主干开发, 团队配合风险大, 开发周期长 l 大包上线, 上线周期长, 风险大 l 新业务, 新需求不断增加, 恶化趋势明显 l 怎么办? 11
- 12. 业务解耦 l 我们已经有了解耦的基础 l Pagelet l Bigpipe l Pagelet服务化 l SOA(Service-Oriented Architecture)的实践 12
- 13. Pagelet服务化 l Pagelet独立开发/上线/运维 l Pagelet通过接口对外提供数据 l Pagelet之间通过L0 Cache来共享数据 13
- 14. Yar – Yet Another RPC Framework l Yar l 开源社区第一个PHP并行RPC框架 l 高效, 轻量级, 易用的RPC框架 l Curl + PHP Stream l PHP, Json, Messagepack l 已开源 14
- 15. 性能优化 - CBigpipe l Yar - 并行化的RPC l Curl Multi + Select(epoll) l Bigpipe + Yar = Concurrent Bigpipe l Pagelets并发渲染 l Fastest Pagelet Renderred first 15
- 16. CBigpipe – Concurrent Bigpipe l CBigpipe l Pagelets并行生成, 谁快谁先到客户端渲染 l 各自独立容灾, 前面的PL失败不会影响后面的PL l 生成时间缩短为”最耗时的PL”生成时间 l 但是, 吞吐下降 l 1 变 M (M << N) 16
- 17. Yar Plus l 前端PHP后端C的服务架构 l Yar + C = Yar C framework l Master/Slaver l 异步模型 l Msgpack l 运维友好 17
- 18. Yar C Framework l 业务面向统一的Yar Client l PHP Service和C Service无缝切换 l 前端PHP后端C的服务架构成型 l 关键词检测服务 l 白名单服务 l 策略服务 l 策略服务为例 l 单机每秒处理请求20K+ 18 0 5000 10000 15000 20000 25000 Yar C Nginx Lua
- 19. Nginx and PHP 5.4 l Nginx l 异步 – 单机承载更多连接, 弥补并行化的吞吐下降, 有利于长连接 l 配置编程 – 更高的配置灵活性 l 二次开发 – 唯一请求ID,替代部分7层功能 l PHP5.4 + Zend Opcache l 迁移代价小, 和5.2的兼容性好 l 大量Bug修复, 大量新特性(Closure, Slow log etc) l 性能提升 (30%) 19
- 20. Zend Opcache l 不仅仅是Opcode Cache l 常量表达式预先计算 l 常数散播 l Numeric offset转换 l Nop移除 l CFG dead block移除 l Literals合并 l 7 ~ 10% 快于APC 20
- 21. Nginx and PHP 5.4(with O +) l 替换的过程很漫长 l 小坑踩了不少 l Libmemcached l Bigpipe和gzip l Rewrite规则改写 l Request_time和lingering_close 21 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 25并发 50并发 Apache Nginx 响应时间对比
- 22. 首屏时间 l 数据填满用户浏览器的时间(800 * 600) l 建立连接时间 + 第一个包处理时间 + 接收时间 + 渲染时间 l 数据来自第三方统计机构 22 3.82 3.17 2.57 2.37 2.24 2.11 1.772 0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 2011Q4 2012Q1 2012Q2 2012Q3 2012Q4 2013Q1 201306
- 23. 唯一请求ID l 服务间调用关系复杂 l 模块依赖繁多 l 出现问题定位耗时, 困难 l 到底是哪个环节出错了? 23
- 24. Yac – Yet Another Cache l Zend Opcache没有User Data Cache l L0 Memcached的代价和维护成本 l 我们User Data Cache的特点 l 内容Cache和用户ID相关 l 内容Cache一般大小固定 l 内容Cache出错的代价 24
- 25. Yac – Lockless cache l Yac l 无锁的共享内存Cache l Last win l 随机LRU l 冲突的解决 l 已开源 25
- 26. 灰度发布系统 l 快速的产品功能验证 l 快速的AB测试 l 快速的新功能迭代 26 分流系统 灰度1 实时日志反馈/分析系统 灰度2 灰度3 …… 分量上线系统 策 略 投 放 管 理 系 统 基于流量 基于用户特征 基于地域
- 27. 灰度发布系统 27
- 28. 代码规范 l 微博应用代码规范.txt, 微博模板开发规范.txt l 代码规范检测平台, 代码提交的时刻实时检查. l 微博应用代码规范.exe, 微博模板开发规范.exe l 技术保障规范的规范, 才是真的规范 28
- 29. 未来? 29 l Nginx l PHP5.4 l Yar and Persistent link l Yaf and Security l 核心包和包管理/发布Cycle (40%) l 灰度发布系统 and 分级上线系统 l 基本服务 and Yar C l …
- 30. 以微博之⼒力, 让世界更美 ! weibo.com 加入我们: http://hr.weibo.com/jobs/