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查询业务或者减少一次Re@R_404_6422@读写

PHP5.6:800 QPS

PHP7.0:1250 QPS

目前优化的结果：

ThinkPHP可以完整的跑在缓存中；

在不需要mySQL查询时，不建立MysqL连接；

不读写re@R_404_6422@时，不建立re@R_404_6422@连接。

以上数据在开发机器使用ab获取，同时也跟其它的框架做了简单对比，性能不低于其它框架。

使用zend debugger profile 可以看到框架层的时间开销占比约24%，相对于yaf这样的C语言框架10%的性能损失，一个包含缓存和ORM的框架已经算比较好的性能了。

再次吐槽一提ThinkPHP框架就喷性能不好的人，任何一个框架拿过来多做几次数据库操作，测试性能都渣得不逼，只测试输出一个HelloWorld并什么卵用。

优化过程

0x00

在项目中早期，开发压力大，没有什么时间进行项目和架构优化。

经过测试，通过添加 MysqL 长连接和re@R_404_6422@长连接，api稳定性得到非常大提升，业务最慢响应时间从4s优化到0.5s，曲线非常平稳。

PHP-FPM单机200进程，2000Request，7台PHP后端，长连接数稳定在1700左右。

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

0x01

经过分析，发现很多API请求，是不需要建立MysqL连接的。调整代码，MysqL的查询逻辑尽量缓存到Re@R_404_6422@里，减少对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

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

为了缓解re@R_404_6422@的读压力，生产中使用了4台Re@R_404_6422@ Standalone做了1主3从架构。

并给ThinkPHP添加Re@R_404_6422@读写分离的支持，减少Re@R_404_6422@的压力。

https://github.com/vus520/thinkPHP/blob/shuhai/db_link_lazzy/ThinkPHP/Library/Think/Cache/Driver/Re@R_404[email protected].PHP

目前存在的问题

Re@R_404_6422@的高可用运维，本身也比较复杂，遇上网络抖动等原因，Re@R_404_6422@会出现同步失败和延迟问题。

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

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

后续的优化计划

对re@R_404_6422@业务进行清理，减少不必要的请求；

压缩内容；

key:value => hash；

一主多从，每个PHP后端部署一个re@R_404_6422@从，优先读本机，减少网络延迟；

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+%的提升