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

Posted 2020-09-18 Leone

需求分析

目前的业务全站使用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+%的提升