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