Weibo Lamp performance improvement

1. 微博LAMP优化之路
-  Laruence 

2. 关于我
l 2005: PHP爱好者, 关注性能
l 2008: www.laruence.com
l 2011: PHP开发组成员
l 2012年: 微博平台及⼤大数据部总架构师
l 2013: Zend公司外聘顾问
l Yaf, Yar, Yac, Lua(PHP), Taint作者
l Opcache, APC, Msgpack, CouchBase贡献者, 维护者
l PHP NG主要作者
2 

3. 关于PHP
3 
l 82.1%的Web服务端脚本语⾔言份额
l 社区活跃, 超过1000的优秀开发⼯工程师直接或间接为PHP贡献
l 版本发布持续, 新功能不断增加, 整体不断完善
l 稳定性不断提⾼高, 速度持续变快
l 最新版本5.6
l 最新开发版7

4. 关于PC微博
4 
l 当时国内最⼤大的LNMP平台
l 每天20亿的PV, >50亿的Hits
l 400台LNMP前端机
l 平均响应时间<300ms
l 峰值每秒10W Hits

5. 最初PC微博
l March, 2012
l Apache Prefork
l PHP-5.2 + APC
l Swift(Simplifiﾞed Kohana)
l Smarty
l BigPipe
5 

6. 最初的PC微博
l 日访问量巨⼤大, 在业务⾼高速增长期, 架构⼀一直没变
l 响应时间越来越慢
l 用户效率, 服务成本, 新产品阻⼒力.
l 代码量庞⼤大, 只做加法不敢做减法
l 开发成本⼤大, 开发周期长
l 开发效率, 新产品阻⼒力
l ⼯工作⽅方向
l 性能优化 – 提速
l 结构优化 – 解耦
6 

7. 性能优化 - Yaf
l Yaf – Yet Another Framework
l 第⼀一个C语⾔言扩展框架, 解决经典的是否使用框架争论
l 兼容PSR0的自动加载
l 基于命名空间的⽂文件目录组织
l ⾼高性能的PHP模板引擎
7 

8. 性能优化 - Weibo Ext
l Weibo扩展
l Weibo Conf
1. 在Apache启动的时候Parse
2. Fork的时候利用COW, ⽽而避免使用共享内存
3. Lookup只需要⼀一个zval的复制(时间复杂度,空间复杂度 O(1))
l Weibo Utils
1. 运算密集型/PHP脚本⽆无法实现的功能
2. 业务⽆无关性
3. ID encode, At, Link, Topic …
8 

9. 性能优化 - PHP Templates
l 弃用Smarty
l Smarty太过庞⼤大
l 不兼容的自动加载规则
l 编译后的模板代码臃肿,低效
l Yaf的视图引擎
l PHP语⾔言本身就是⼀一个很好的模板语⾔言
9 

10. 性能优化
10 
l 响应时间下降
44%
l 吞吐提升
78%
l CPU利用率下降
l 内存占用率下降

11. 结构优化 – 解耦
l 解耦的基础
l Pagelet
l Bigpipe
l Pagelet服务化
l SOA(Service-Oriented Architecture)的实践
11 

12. 结构优化 – Pagelets服务化
l 统⼀一的Pagelets开发,测试模式
l Pagelets独立开发, 上线, 运维
l Pagelets通过接⼝口对外提供数据
l Pagelets之间通过Cache共享数据
l 需要⼀一个极度⾼高效的RPC
12 

13. 结构优化– Yar
l Yar - Yet Another RPC frmawork
l 第⼀一个PHP并⾏行RPC框架
l ⾼高效, 轻量级, 易用的RPC框架
l 支持HTTP, Socket俩种⽅方式
l 支持Msgpack, Json
13 

14. 结构优化带来的性能优化 - CBigpipe
l Yar - 并⾏行化的RPC
l Curl Multi + Select(epoll)
l Bigpipe + Yar = Concurrent Bigpipe
l Pagelets并发渲染
l Fastest Pagelet Renderred fiﾞrst
14 

15. CBigpipe – Concurrent Bigpipe
l CBigpipe
l Pagelets并⾏行⽣生成, 谁快谁先到客户端渲染
l 各自独立容灾, 前面的PL失败不会影响后面的PL
l ⽣生成时间缩短为”最耗时的PL”⽣生成时间
l 但是, 吞吐下降
l 1 变 M (M << N)
15 

16. 结构优化 – 前端PHP后端C
l 经典的服务架构
l Yar + C = Yar C framework
l Master/Slaver
l 异步模型
l Msgpack
l 运维友好
16 

17. 结构优化 – 前端PHP后端C
l 业务面向统⼀一的Yar Client
l PHP Service和C Service⽆无缝切换
l 前端PHP后端C的服务架构成型
l 关键词检测服务
l 白名单服务
l 策略服务
l 策略服务为例
l 单机每秒处理请求20K+
17 
0
5000
10000
15000
20000
25000
Yar C Nginx Lua

18. 基础优化 – LAMP到LNMP
l Nginx
l 异步 – 单机承载更多连接, 弥补并⾏行化的吞吐下降, 有利于长连接
l 配置编程 – 更⾼高的配置灵活性
l ⼆二次开发 – 唯⼀一请求ID,替代部分7层功能
l PHP5.4
l 迁移代价小, 和5.2的兼容性好
l ⼤大量Bug修复, ⼤大量新特性(Closure, Slow log etc)
l 性能提升 (30%)
18 

19. 基础优化 – LAMP到LNMP
l 替换的过程很漫长
l 小坑踩了不少
l Libmemcached
l Bigpipe和gzip
l Rewrite规则改写
l Request_time和lingering_close
19 
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
25并发  50并发 
Apache
Nginx
响应时间对比 

20. 基础优化 – O+替换APC
l O+不仅仅是Opcodes Cache
l 常量表达式预先计算
l 常数散播
l Numeric offset转换
l Nop移除
l CFG dead block移除
l Literals合并
l 7 ~ 10% 快于APC
20 

21. 基础优化 – O+替换APC
l 替换的效果
l 7月26日全部替换完成
l 替换瞬间的服务器各项指标变化
21 

22. 性能优化 – Yac
l Yac – Yet Another Cache
l Zend O+没有User Data Cache
l L0 Memcached的代价和维护成本
l 我们User Data Cache的特点
l 内容Cache和用户ID相关
l 内容Cache⼀一般⼤大小固定
l 内容Cache出错的代价
l 敏感位确定有规律
22 

23. 性能优化 – Yac
l Yac
l ⽆无锁的共享内存Cache
l Last win
l 随机LRU
l 冲突的解决
23 

24. 总瞰 – 首屏时间
l 数据填满用户浏览器的时间(800 * 600)
l 建立连接时间 + 第⼀一个包处理时间 + 接收时间 + 渲染时间
l 数据来自第三⽅方统计机构
24 
3.82
3.17
2.57
2.37 2.24 2.11
1.56
1.36
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 201310

25. 微博⾼高性能LNMP框架
l 微博⾼高性能框架达成
25 
H F G
F HGD H Access control
. . F DHG
B DH A M F . IG
C CB C H G HH LH
DD H CB F A CF
F . F A CFA
G D
C C
Yar C Service Yar PHP ServiceYar Java APICache
EI GH
D D D D & .

26. 移动Server优化
l 移动业务重要性不断提升
l 来自移动的请求已经占到了70%以上
l 每天80亿的Hits
l 前端机有近1000台
l 爆炸式增长凸现MAPI的问题
•･ 服务器压⼒力⼤大
•･ 移动机房4月最低到5%
26 
A
C

27. 移动Server优化
l ⾼高性能服务统⼀一解决⽅方案
l PHP”异步”调用解决⽅方案
l 基于Flex和Bison实现的Jsond
l 更加强⼤大的Zend Optimizer +
l 运维优化
l KeepAlive
l 会话保持
l 唯⼀一请求ID
27 

28. “异步”调用解决⽅方案
l Feed接⼝口依赖于俩个重型接⼝口, Feed和趋势(推荐)
l 接⼝口有先后顺序依赖(未读数), ⽆无法并⾏行化
l 基于IO复用实现的”异步调用”实⾏行了”并⾏行化
l 基于IO复用(Curl Multi)
l 依赖TCP可靠的传输应答机制
l 延时读取TCP栈数据
28 
- -
-
/

29. 优化结果
l 平均TPS提升154%, 峰值TPS提升168%
l 平均响应时间下降61%
l 满载CPU负载下降10%
29 

30. 上线以后
l 节省逻辑服务器777台
l 以⽹网通机房为例, 60台服务器, 替代了原来的300台服务器.
l 实际下线实体机400台
l 服务器冗余度提升到~3倍
30 
⽹网通机房4月⼀一周平均负载  ⽹网通机房9月⼀一周平均负载 

31. 以微博之⼒力, 让世界更美 !
weibo.com