需求分析
目前的業務全站使用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+%的提升