13518219792
1、采用長連接連接數據庫2、一次性讀取查詢結果到本地（mysqli_result::store_result、pdo::fetchall）
網站建設哪家好，找創新互聯公司！專注于網頁設計、網站建設、微信開發、微信小程序、集團企業網站建設等服務項目。為回饋新老客戶創新互聯還提供了大余免費建站歡迎大家使用！
緣起
關于PHP 很多人的直觀感覺是PHP是一種靈活的腳本語言 庫類豐富 使用簡單 安全 非常適合WEB開發 但性能低下 PHP的性能是否真 的就如同大家的感覺一樣的差呢？本文就是圍繞這么一個話題來進行探討的 從源碼 應用場景 基準性能 對比分析等幾個方面深入分析PHP之性能問題 并通 過真實的數據來說話
從原理分析PHP性能
從原理分析PHP的性能 主要從以下幾個方面 內存管理 變量 函數 運行機制來進行分析
內存管理
類似Nginx的內存管理方式 PHP在內部也是基于內存池 并且引入內存池的生命周期概念 在內存池方面 PHP對PHP腳本和擴展的所有內 存相關操作都進行了托管 對大內存和小內存的管理采用了不同的實現方式和優化 具體可以參考以下文檔 在內存分配和回收的生命周期內 PHP采用一次初始化申請+動態擴容+內存標識回收機制 并且在每次請求結束后直 接對內存池進行重新mask
變量
總所周知 PHP是一種弱變量類型的語言 所以在PHP內部 所有的PHP變量都對應成一種類型Zval 其中具體定義如下
圖一PHP變量
在變量方面 PHP做了大量的優化工作 比如說Reference counting和copy on writer機制 這樣能夠保證內存使用上的優化 并且減少內存拷貝次數（請參考） 在數組方面 PHP內部采用高效的hashtable來實現
函數
在PHP內部 所有的PHP函數都回轉化成內部的一個函數指針 比如說擴展中函數
ZEND_FUNCTION?(?my_function?);//類似function?my_function(){}
在內部展開后就會是一個函數
void?zif_my_function?(?INTERNAL_FUNCTION_PARAMETERS?);
void?zif_my_function(
int?ht
zval?*?return_value
zval?*?this_ptr
int?return_value_used
zend_executor_globals?*?executor_globals
);
從這個角度來看 PHP函數在內部也是對應一個函數指針
運行機制
在話說PHP性能的時候 很多人都會說“C/C++是編譯型 JAVA是半編譯型 PHP是解釋型” 也就是說PHP是先動態解析再代碼運行的 所以從這個角度來看 PHP性能必然很差
的確 從PHP腳本運行來輸出 的確是一個動態解析再代碼運行的過程 具體來說 PHP腳本的運行機制如下圖所示
圖二 PHP運行機制
PHP的運行階段也分成三個階段
Parse 語法分析階段
Compile 編譯產出opcode中間碼
Execute 運行 動態運行進行輸出
所以說 在PHP內部 本身也是存在編譯的過程 并且據此產生了大量的opcode cache工具 比如說apc eacc xcache等等 這些opcode cache在生產環境基本上在標配 基于opcode cache 能到做到“PHP腳本編譯一次 多次運行”的效果 從這點上 PHP就和JAVA的半編譯機制非常類似
所以 從運行機制上來看 PHP的運行模式和JAVA是非常類似的 都是先產生中間碼 然后運行在不同虛擬機上
動態運行
從上面的幾個分析來看 PHP在內存管理 變量 函數 運行機制等幾個方面都做了大量的工作 所以從原理來看 PHP 不應該存在性能問題 性能至少也應該和Java 比較接近
這個時候就不得不談PHP動態語言的特性所帶來的性能問題了 由于PHP是動態運行時 所以所有的變量 函數 對象調用 作用域實現等等都是在 執行階段中才確定的 這個從根本上決定了PHP性能中很難改變的一些東西 在C/C++等能夠在靜態編譯階段確定的變量 函數 在PHP中需要在動態運行 中確定 也就決定了PHP中間碼不能直接運行而需要運行在Zend Engine上
說到PHP變量的具體實現 又不得不說一個東西了 Hashtable Hashtable可以說在PHP靈魂之一 在PHP內部廣泛用到 包含變量符號棧 函數符號棧等等都是基于hashtable的
以PHP變量為例來說明下PHP的動態運行特點 比如說代碼
?php
$var?=?“hello ?blog xiuwz ”;
?
該代碼的執行結果就是在變量符號棧（是一個hashtable）中新增一個項
當要使用到該變量時候 就去變量符合棧中去查找（也就是變量調用對出了一個hash查找的過程）
同樣對于函數調用也基本上類似有一個函數符號棧（hashtable）
其實關于動態運行的變量查找特點 在PHP的運行機制中也能看出一些 PHP代碼通過解釋 編譯后的流程下圖
圖 PHP運行實例
從上圖可以看出 PHP代碼在pile之后 產出的了類符號表 函數符號表 和OPCODE 在真正執行的時候 zend Engine會根據op code去對應的符號表中進行查找 處理
從某種程度上 在這種問題的上 很難找到解決方案 因為這是由于PHP語言的動態特性所決定的 但是在國內外也有不少的人在尋找解決方案 因為 通過這樣 能夠從根本上完全的優化PHP 典型的列子有facebook的hiphop
結論
從上面分析來看 在基礎的內存管理 變量 函數 運行機制方面 PHP本身并不會存在明顯的性能差異 但由于PHP的動態運行特性 決定了 PHP和其他的編譯型語言相比 所有的變量查找 函數運行等等都會多一些hash查找的CPU開銷和額外的內存開銷 至于這種開銷具體有多大 可以通過后 續的基準性能和對比分析得出
因此 也可以大體看出PHP不太適合的一些場景 大量計算性任務 大數據量的運算 內存要求很嚴格的應用場景 如果要實現這些功能 也建議通過擴展的方式實現 然后再提供鉤子函數給PHP調用 這樣可以減低內部計算的變量 函數等系列開銷
基準性能
對于PHP基準性能 目前缺少標準的數據 大多數同學都存在感性的認識 有人認為 QPS就是PHP的極限了 此外 對于框架的性能和框架對性能的影響很沒有響應的權威數字
本章節的目的是給出一個基準的參考性能指標 通過數據給大家一個直觀的了解
具體的基準性能有以下幾個方面
裸PHP性能 完成基本的功能
裸框架的性能 只做最簡單的路由分發 只走通核心功能
標準模塊的基準性能 所謂標準模塊的基準性能 是指一個具有完整服務模塊功能的基準性能
環境說明
測試環境
Uname aPnux db forum test db baidu _ # SMP Wed Aug : : CST x _ x _ x _ GNU/Pnux
Red Hat Enterprise Pnux AS release (Nahant Update )
Intel(R) Xeon(R) CPU?????????? E ? @ GHz
軟件相關
Nginx nginx version: nginx/ ? built by gcc (Red Hat )
Php （采用php fpm）
PHP (cP) (built: Mar? : : )
Copyright (c) The PHP Group
Zend Engine v Copyright (c) Zend Technologies
with eAccelerator v Copyright (c) eAccelerator by eAccelerator
bingo
PHP框架
其他說明
目標機器的部署方式 nginx php fpm php腳本
測試壓力機器和目標機器獨立部署
裸PHP性能
最簡單的PHP腳本
?php
require_once?‘ /actions/indexAction php’;
$objAction?=?new?indexAction();
$objAction init();
$objAction execute();
?
Acitons/indexAction php里面的代碼如下
?php
class?indexAction
{
pubPc?function?execute()
{
echo?‘hello ?world!’;
}
}
?
通過壓力工具測試結果如下
裸PHP框架性能
為了和 的對比 基于bingo 框架實現了類似的功能 代碼如下
?php
require_once?‘Bingo/Controller/Front php’;
$objFrontController?=?Bingo_Controller_Front::getInstance(array(
‘actionDir’?=?‘ /actions’
));
$objFrontController dispatch();
壓力測試結果如下
從該測試結果可以看出 框架雖然有一定的消耗 但對整體的性能來說影響是非常小的
標準PHP模塊的基準性能
所謂標準PHP模塊 是指一個PHP模塊所必須要具體的基本功能
路由分發
自動加載
LOG初始化Notice日志打印 所以的UI請求都一條標準的日志
錯誤處理
時間校正
自動計算每個階段耗時開銷
編碼識別編碼轉化
標準配置文件的解析和調用
采用bingo 的代碼自動生成工具產生標準的測試PHP模塊 test
測試結果如下
結論
從測試數據的結論來看 PHP本身的性能還是可以的 基準性能完全能夠達到幾千甚至上W的QPS 至于為什么在大多數的PHP模塊中表現不佳 其實這個時候更應該去找出系統的瓶頸點 而是簡單的說OK PHP不行 那我們換C來搞吧 （下一個章節 會通過一些例子來對比 采用C來處理不見得有特 別的優勢）
通過基準數據 可以得出以下幾個具體的結論
PHP本身性能也很不錯 簡單功能下能夠達到 QPS 極限也能過W
PHP框架本身對性能影響非常有限 尤其是在有一定業務邏輯和數據交互的情況下 幾乎可以忽略
一個標準的PHP模塊 基準性能能夠達到 QPS（ cpu idle）
對比分析
lishixinzhi/Article/program/PHP/201311/21287
你可以將10W條分批寫入，在循環里加個判斷，當數組中的個數達到500或者1000條時，批量寫入一次，循環結束后，不管數據有沒有達到你設定的這個值，只要有數據都再寫入一次就可以了。
