大話PHP之效能

發表於2011-11-29

1 緣起

關於PHP,很多人的直觀感覺是PHP是一種靈活的指令碼語言,庫類豐富,使用簡單,安全,非常適合WEB開發,但效能低下。PHP的效能是否真的就 如同大家的感覺一樣的差呢?本文就是圍繞這麼一個話題來進行探討的。從原始碼、應用場景、基準效能、對比分析等幾個方面深入分析PHP之效能問題,並通過真 實的資料來說話。

2 從原理分析PHP效能

從原理分析PHP的效能,主要從以下幾個方面:記憶體管理、變數、函式、執行機制來進行分析。

2.1記憶體管理

類似Nginx的記憶體管理方式,PHP在內部也是基於記憶體池,並且引入記憶體池的生命週期概念。在記憶體池方面,PHP對PHP指令碼和擴充套件的所有記憶體相關操作都進行了託管。對大記憶體和小記憶體的管理採用了不同的實現方式和優化,具體可以參考以下文件:https://wiki.php.net/internals/zend_mm。在記憶體分配和回收的生命週期內,PHP採用一次初始化申請+動態擴容+記憶體標識回收機制,並且在每次請求結束後直接對記憶體池進行重新mask。

2.2變數

總所周知,PHP是一種弱變數型別的語言,所以在PHP內部,所有的PHP變數都對應成一種型別Zval,其中具體定義如下:

大話PHP之效能

圖一、PHP變數

在變數方面,PHP做了大量的優化工作,比如說Reference counting和copy on writer機制。這樣能夠保證記憶體使用上的優化,並且減少記憶體拷貝次數(請參考http://blog.xiuwz.com/2011/11/09 /php-using-internal-zval/)。在陣列方面,PHP內部採用高效的hashtable來實現。

2.3函式

在PHP內部,所有的PHP函式都回轉化成內部的一個函式指標。比如說擴充套件中函式

在內部展開後就會是一個函式

從這個角度來看,PHP函式在內部也是對應一個函式指標。

2.4執行機制

在話說PHP效能的時候,很多人都會說“C/C++是編譯型,JAVA是半編譯型,PHP是解釋型”。也就是說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是非常類似的,都是先產生中間碼,然後執行在不同虛擬機器上。

2.5動態執行

從上面的幾個分析來看,PHP在記憶體管理、變數、函式、執行機制等幾個方面都做了大量的工作,所以從原理來看,PHP不應該存在效能問題,效能至少也應該和JAVA比較接近

這個時候就不得不談PHP動態語言的特性所帶來的效能問題了,由於PHP是動態執行時,所以所有的變數、函式、物件呼叫、作用域實現等等都是在執行 階段中才確定的。這個從根本上決定了PHP效能中很難改變的一些東西:在C/C++等能夠在靜態編譯階段確定的變數、函式,在PHP中需要在動態執行中確 定,也就決定了PHP中間碼不能直接執行而需要執行在Zend Engine上。

說到PHP變數的具體實現,又不得不說一個東西了:hashtable。Hashtable可以說在PHP靈魂之一,在PHP內部廣泛用到,包含變數符號棧、函式符號棧等等都是基於hashtable的。

以PHP變數為例來說明下PHP的動態執行特點,比如說程式碼:

該程式碼的執行結果就是在變數符號棧(是一個hashtable)中新增一個項

大話PHP之效能

當要使用到該變數時候,就去變數符合棧中去查詢(也就是變數呼叫對出了一個hash查詢的過程)。

同樣對於函式呼叫也基本上類似有一個函式符號棧(hashtable)。

其實關於動態執行的變數查詢特點,在PHP的執行機制中也能看出一些。PHP程式碼通過解釋、編譯後的流程下圖:

大話PHP之效能

圖3、PHP執行例項

從上圖可以看出,PHP程式碼在compile之後,產出的了類符號表、函式符號表、和OPCODE。在真正執行的時候,zend Engine會根據op code去對應的符號表中進行查詢,處理。

從某種程度上,在這種問題的上,很難找到解決方案。因為這是由於PHP語言的動態特性所決定的。但是在國內外也有不少的人在尋找解決方案。因為通過這樣,能夠從根本上完全的優化PHP。典型的列子有facebook的hiphop(https://github.com/facebook/hiphop-php)。

2.6結論

從上面分析來看,在基礎的記憶體管理、變數、函式、執行機制方面,PHP本身並不會存在明顯的效能差異,但由於PHP的動態執行特性,決定了PHP和 其他的編譯型語言相比,所有的變數查詢、函式執行等等都會多一些hash查詢的CPU開銷和額外的記憶體開銷,至於這種開銷具體有多大,可以通過後續的基準 效能和對比分析得出。

因此,也可以大體看出PHP不太適合的一些場景:大量計算性任務、大資料量的運算、記憶體要求很嚴格的應用場景。如果要實現這些功能,也建議通過擴充套件的方式實現,然後再提供鉤子函式給PHP呼叫。這樣可以減低內部計算的變數、函式等系列開銷。

3基準效能

對於PHP基準效能,目前缺少標準的資料。大多數同學都存在感性的認識,有人認為800QPS就是PHP的極限了。此外,對於框架的效能和框架對效能的影響很沒有響應的權威數字。

本章節的目的是給出一個基準的參考效能指標,通過資料給大家一個直觀的瞭解。

具體的基準效能有以下幾個方面:

1、  裸PHP效能。完成基本的功能。

2、  裸框架的效能。只做最簡單的路由分發,只走通核心功能。

3、  標準模組的基準效能。所謂標準模組的基準效能,是指一個具有完整服務模組功能的基準效能。

3.1環境說明

測試環境:

Uname -a

Linux db-forum-test17.db01.baidu.com 2.6.9_5-7-0-0 #1 SMP Wed Aug 12 17:35:51 CST 2009 x86_64 x86_64 x86_64 GNU/Linux

Red Hat Enterprise Linux AS release 4 (Nahant Update 3)

8  Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz

軟體相關:

Nginx:

nginx version: nginx/0.8.54  built by gcc 3.4.5 20051201 (Red Hat 3.4.5-2)

Php5:(採用php-fpm)

PHP 5.2.8 (cli) (built: Mar  6 2011 17:16:18)

Copyright (c) 1997-2008 The PHP Group

Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator

bingo2:

PHP框架。

其他說明:

目標機器的部署方式:大話PHP之效能 指令碼。

測試壓力機器和目標機器獨立部署。

3.2裸PHP效能

最簡單的PHP指令碼。

 

 

通過壓力工具測試結果如下:

大話PHP之效能

3.3裸PHP框架效能

為了和3.2的對比,基於bingo2框架實現了類似的功能。程式碼如下

 

 

壓力測試結果如下:

大話PHP之效能

從該測試結果可以看出:框架雖然有一定的消耗,但對整體的效能來說影響是非常小的

3.4標準PHP模組的基準效能

所謂標準PHP模組,是指一個PHP模組所必須要具體的基本功能:

路由分發。

自動載入。

LOG初始化&Notice日誌列印。所以的UI請求都一條標準的日誌。

●錯誤處理。

●時間校正。

●自動計算每個階段耗時開銷。

●編碼識別&編碼轉化。

●標準配置檔案的解析和呼叫

●採用bingo2的程式碼自動生成工具產生標準的測試PHP模組:test。

測試結果如下:

大話PHP之效能

3.5結論

從測試資料的結論來看,PHP本身的效能還是可以的。基準效能完全能夠達到幾千甚至上W的QPS。至於為什麼在大多數的PHP模組中表現不佳,其實 這個時候更應該去找出系統的瓶頸點,而是簡單的說OK,PHP不行,那我們換C來搞吧。(下一個章節,會通過一些例子來對比,採用C來處理不見得有特別的 優勢)

通過基準資料,可以得出以下幾個具體的結論:

1、    PHP本身效能也很不錯。簡單功能下能夠達到5000QPS,極限也能過W。

2、    PHP框架本身對效能影響非常有限。尤其是在有一定業務邏輯和資料互動的情況下,幾乎可以忽略。

3、    一個標準的PHP模組,基準效能能夠達到2000QPS(80 cpu idle)。

4對比分析

很多時候,大家發現PHP模組效能不行的時候,就來一句“ok,我們採用C重寫吧”。在公司內,採用C/C++來寫業務邏輯模組的現象到處都有,在前幾年甚至幾乎全部都是採用C來寫。那時候大家寫的真是一個痛苦:除錯難、敏捷不要談。

那麼,本章節要談論的一個話題就是:C寫的業務邏輯和PHP寫的業務邏輯模組進行效能對比,採用真實的資料來說話。

4.1前提

為什麼要特別說出這個前提呢?因為在理想情況下,一個功能採用PHP實現,該效能鐵定不可能比理想的C寫出來好。這個前提需要特別注意。

但為什麼還要對比呢?因為在現實情況下,能寫出非常有些的C程式,並且在頻繁修改的情況下還能做到完全高效能的又有幾個呢?

所以,本章節的對比是基於現實中的情況來進行的。

4.2 貼吧的feye和pbui效能對比

Feye和pbui是貼吧帖子列表頁面的業務層模組。

參考文件:

http://yanbin.org/

https://wiki.php.net/internals/zend_mm

http://blog.xiuwz.com/2011/11/09/php-using-internal-zval/

http://developers.facebook.com/blog/post/358/

https://github.com/facebook/hiphop-php

相關文章