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/thinkphp/tree/shuhai/db_link_lazzy

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

0x03

当业务都严重依赖redis时，Redis的QPS一度飙升到7k，内存占用6G左右。

为了缓解redis的读压力，生产中使用了4台Redis Standalone作了1主3从架构。

并给ThinkPHP添加Redis读写分离的支持，减小Redis的压力。

https://github.com/vus520/thinkphp/blob/shuhai/db_link_lazzy/ThinkPHP/Library/Think/Cache/Driver/Redisd.class.php

目前存在的问题

Redis的高可用运维，自己也比较复杂，赶上网络抖动等缘由，Redis会出现同步失败和延迟问题。

特别是在云服务器架构的环境中，网络瓶颈和延迟问题对分布式应用有很是大的影响。

很惋惜，咱们目前使用的青云，目前尚不能实现Redis超高可用，也不能实现无缝扩容，私网内的网络传输性能、延迟都有很大优化空间。

后续的优化计划

对redis业务进行清理，减小没必要要的请求；

压缩内容；

key:value => hash；

一主多从，每一个php后端部署一个redis从，优先读本机，减小网络延迟；

0x04

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

https://github.com/vus520/thinkphp/tree/shuhai/tiny

• 1，去掉路由
• 2，去掉URL调度
• 3，去掉行为、Hook
• 4，去掉视图
• 5，去掉控制器的反射、空操做
• 6，去掉Session，可实现无状态的Api

0x05

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