ThinkPHP 3.2 性能优化，实现高性能API开发

需求分析

目前的业务全站使用ThinkPHP 3.2.3，前台、后台、Cli、Api等。目前的业务API访问量数千万，后端7台PHP 5.6，平均CPU使用率20%。

测试数据

真实业务
php5.6:500 QPS
php7.0:850 QPS

真实业务中减少一次Mysql查询业务或者减少一次Redis读写
php5.6:800 QPS
php7.0:1250 QPS

目前优化的结果：
ThinkPHP可以完整的跑在缓存中；
在不需要mysql查询时，不建立mysql连接；
不读写redis时，不建立redis连接。

以上数据在开发机器使用ab获取，同时也跟其它的框架做了简单对比，性能不低于其它框架。
使用zend debugger profile 可以看到框架层的时间开销占比约24%，相对于yaf这样的C语言框架10%的性能损失，一个包含缓存和ORM的框架已经算比较好的性能了。
再次吐槽一提ThinkPHP框架就喷性能不好的人，任何一个框架拿过来多做几次数据库操作，测试性能都渣得不逼，只测试输出一个HelloWorld并什么卵用。

优化过程

0x00

在项目中早期，开发压力大，没有什么时间进行项目和架构优化。
经过测试，通过添加 mysql 长连接和redis长连接，api稳定性得到非常大提升，业务最慢响应时间从4s优化到0.5s，曲线非常平稳。
PHP-FPM单机200进程，2000Request，7台PHP后端，长连接数稳定在1700左右。

产生的问题
长连接数超过5k时，性能会下降。出现过两次Mysql Server 内存用光的情况。

0x01

经过分析，发现很多API请求，是不需要建立Mysql连接的。调整代码，Mysql的查询逻辑尽量缓存到Redis里，减少对Mysql的压力。
同时对ThinkPHP的代码逻辑进行化，调用 Model 中的方法、属性，不建立Mysql连接，只有在读写db时才建立连接。减少了非常多的资源开销。
经过上述调整，Mysql的连接从1700下降到100以内，query and read QPS从5k下降到50。

优化的ThinkPHP的代码已推送到Github:

https://github.com/vus520/thi...

后续是对ThinkPHP中Mysql主从、读写分离进行深度测试，增加Mysql的读能力。

0x03

当业务都严重依赖redis时，Redis的QPS一度飙升到7k，内存占用6G左右。
为了缓解redis的读压力，生产中使用了4台Redis Standalone做了1主3从架构。
并给ThinkPHP添加Redis读写分离的支持，减少Redis的压力。

https://github.com/vus520/thi...

目前存在的问题
Redis的高可用运维，本身也比较复杂，遇上网络抖动等原因，Redis会出现同步失败和延迟问题。
特别是在云服务器架构的环境中，网络瓶颈和延迟问题对分布式应用有非常大的影响。
很可惜，我们目前使用的青云，目前尚不能实现Redis超高可用，也不能实现无缝扩容，私网内的网络传输性能、延迟都有很大优化空间。

后续的优化计划
对redis业务进行清理，减少不必要的请求；
压缩内容；
key:value => hash；
一主多从，每个php后端部署一个redis从，优先读本机，减少网络延迟；

0x04

API项目中，禁用ThinkPHP的Session、路由、视图、行为等，进行精简加速。
经测试，性能有30%的提升。

https://github.com/vus520/thi...

• 1，去掉路由

• 2，去掉URL调度

• 3，去掉行为、Hook

• 4，去掉视图

• 5，去掉控制器的反射、空操作

• 6，去掉Session，可实现无状态的Api

0x05

在PHP7中进行深度测试，升级到PHP7，ThinkPHP 3.2的性能会有50+%的提升

0x06

http://www.4wei.cn/archives/1...

0x07

php7.1版本发布以后，phpredis存储压缩数据的bug解决掉了，目前线上生产中的节点，升级到php7以后，CPU和内存都有接近50%的下降，机器可以缩减一半，成本也降低不少。