學習PHP7的革新與效能優化

2020-07-16 10:06:14

PHP已經走過了20年的歷史,PHP7對於上一個系列的PHP5,可以說是一個大規模的革新,尤其是在效能方面實現跨越式的大幅提升。PHP是一種在全球範圍內被廣泛使用的Web開發語言,PHP7的革新也當然會給這些Web服務帶來更深刻的變化。

這裡參照鳥哥PPT中的一個圖表(82%的Web站點有使用PHP作為開發語言):

(註:一個web站點可以會使用多種語言作為它的開發語言)
(註:本文含有不少從鳥哥PPT裡的截圖,圖片版權歸鳥哥所有)

我們先看看兩張激動人心的效能測試結果圖


PHP7的效能測試結果,效能壓測結果,耗時從2.991下降到1.186,大幅度下降60%。

WordPress的QPS壓測(圖片來自於PPT):

而在WordPress專案中,PHP7對比PHP5.6,QPS提升2.77倍。

看完令人激動的效能測試結果對比,我們就進入正題哈。PHP7的新增特性很多,不過,我們會更聚焦於那些主要的變化。

一、新增特性和改變

1. 標量型別和返回型別宣告(Scalar Type Declarations & Scalar Type Declarations)

PHP語言一個非常重要的特點就是「弱型別」,它讓PHP的程式變得非常容易編寫,新手接觸PHP能夠快速上手,不過,它也伴隨著一些爭議。支援變數型別的定義,可以說是革新性質的變化,PHP開始以可選的方式支援型別定義。除此之外,還引入了一個開關指令declare(strict_type=1);,當這個指令一旦開啟,將會強制當前檔案下的程式遵循嚴格的函數傳參型別和返回型別。

例如一個add函數加上型別定義,可以寫成這樣:

如果配合強制型別開關指令,則可以變為這樣:

如果不開啟strict_type,PHP將會嘗試幫你轉換成要求的型別,而開啟之後,會改變PHP就不再做型別轉換,型別不匹配就會丟擲錯誤。對於喜歡「強型別」語言的同學來說,這是一大福音。

更為詳細的介紹:PHP7標量型別宣告RFC[翻譯]

2. 更多的Error變為可捕獲的Exception

PHP7實現了一個全域性的throwable介面,原來的Exception和部分Error都實現了這個介面(interface), 以介面的方式定義了異常的繼承結構。於是,PHP7中更多的Error變為可捕獲的Exception返回給開發者,如果不進行捕獲則為Error,如果捕獲就變為一個可在程式內處理的Exception。這些可被捕獲的Error通常都是不會對程式造成致命傷害的Error,例如函數不存。PHP7進一步方便開發者處理,讓開發者對程式的掌控能力更強。因為在預設情況下,Error會直接導致程式中斷,而PHP7則提供捕獲並且處理的能力,讓程式繼續執行下去,為程式設計師提供更靈活的選擇。

例如,執行一個我們不確定是否存在的函數,PHP5相容的做法是在函數被呼叫之前追加的判斷function_exist,而PHP7則支援捕獲Exception的處理方式。

如下圖中的例子(截圖來源於PPT內):

3. AST(Abstract Syntax Tree,抽象語法樹)

AST在PHP編譯過程作為一個中介軟體的角色,替換原來直接從直譯器吐出opcode的方式,讓直譯器(parser)和編譯器(compliler)解耦,可以減少一些Hack程式碼,同時,讓實現更容易理解和可維護。
PHP5:

PHP7:

更多AST資訊:https://wiki.php.net/rfc/abstract_syntax_tree

4. Native TLS(Native Thread local storage,原生執行緒本地儲存)

PHP在多執行緒模式下(例如,Web伺服器Apache的woker和event模式,就是多執行緒),需要解決「執行緒安全」(TS,Thread Safe)的問題,因為執行緒是共用進程的記憶體空間的,所以每個執行緒本身需要通過某種方式,構建私有的空間來儲存自己的私有資料,避免和其他執行緒相互汙染。而PHP5採用的方式,就是維護一個全域性大陣列,為每一個執行緒分配一份獨立的儲存空間,執行緒通過各自擁有的key值來存取這個全域性資料組。

而這個獨有的key值在PHP5中需要傳遞給每一個需要用到全域性變數的函數,PHP7認為這種傳遞的方式並不友好,並且存在一些問題。因而,嘗試採用一個全域性的執行緒特定變數來儲存這個key值。
相關的Native TLS問題:
https://wiki.php.net/rfc/native-tls

5. 其他新特性

PHP7新特性和變化不少,我們這裡並不全部展開來細說哈。
(1) Int64支援,統一不同平台下的整型長度,字串和檔案上傳都支援大於2GB。
(2) 統一變數語法(Uniform variable syntax)。
(3) foreach表現行為一致(Consistently foreach behaviors)
(4) 新的操作符 <=>, ??
(5) Unicode字元格式支援(u{xxxxx})
(6) 匿名類支援(Anonymous Class)
… …

二、跨越式的效能突破:全速前進

1. JIT與效能

Just In Time(即時編譯)是一種軟體優化技術,指在執行時才會去編譯位元組碼為機器碼。從直覺出發,我們都很容易認為,機器碼是計算機能夠直接識別和執行的,比起Zend讀取opcode逐條執行效率會更高。其中,HHVM(HipHop Virtual Machine,HHVM是一個Facebook開源的PHP虛擬機器)就採用JIT,讓他們的PHP效能測試提升了一個數量級,放出一個令人震驚的測試結果,也讓我們直觀地認為JIT是一項點石成金的強大技術。
而實際上,在2013年的時候,鳥哥和Dmitry(PHP語言核心開發者之一)就曾經在PHP5.5的版本上做過一個JIT的嘗試(並沒有發布)。PHP5.5的原來的執行流程,是將PHP程式碼通過詞法和語法分析,編譯成opcode位元組碼(格式和組合有點像),然後,Zend引擎讀取這些opcode指令,逐條解析執行。

而他們在opcode環節後引入了型別推斷(TypeInf),然後通過JIT生成ByteCodes,然後再執行。

於是,在benchmark(測試程式)中得到令人興奮的結果,實現JIT後效能比PHP5.5提升了8倍。然而,當他們把這個優化放入到實際的專案WordPress(一個開源部落格專案)中,卻幾乎看不見效能的提升,得到了一個令人費解的測試結果。
於是,他們使用Linux下的profile型別工具,對程式執行進行CPU耗時占用分析。
執行100次WordPress的CPU消耗的分布(截圖來自PPT):

註解:
21%CPU時間花費在記憶體管理。
12%CPU時間花費在hash table操作,主要是PHP陣列的增刪改查。
30%CPU時間花費在內建函數,例如strlen。
25%CPU時間花費在VM(Zend引擎)。

經過分析之後,得到了兩個結論:

(1)JIT生成的ByteCodes如果太大,會引起CPU快取命中率下降(CPU Cache Miss)

在PHP5.5的程式碼裡,因為並沒有明顯型別定義,只能靠型別推斷。盡可能將可以推斷出來的變數型別,定義出來,然後,結合型別推斷,將非該型別的分支程式碼去掉,生成直接可執行的機器碼。然而,型別推斷不能推斷出全部型別,在WordPress中,能夠推斷出來的型別資訊只有不到30%,能夠減少的分支程式碼有限。導致JIT以後,直接生成機器碼,生成的ByteCodes太大,最終引起CPU快取命中大幅度下降(CPU Cache Miss)。

CPU快取命中是指,CPU在讀取並執行指令的過程中,如果需要的資料在CPU一級快取(L1)中讀取不到,就不得不往下繼續尋找,一直到二級快取(L2)和三級快取(L3),最終會嘗試到記憶體區域裡尋找所需要的指令資料,而記憶體和CPU快取之間的讀取耗時差距可以達到100倍級別。所以,ByteCodes如果過大,執行指令數量過多,導致多級快取無法容納如此之多的資料,部分指令將不得不被存放到記憶體區域。

CPU的各級快取的大小也是有限的,下圖是Intel i7 920的設定資訊:

因此,CPU快取命中率下降會帶來嚴重的耗時增加,另一方面,JIT帶來的效能提升,也被它所抵消掉了。

通過JIT,可以降低VM的開銷,同時,通過指令優化,可以間接降低記憶體管理的開發,因為可以減少記憶體分配的次數。然而,對於真實的WordPress專案來說,CPU耗時只有25%在VM上,主要的問題和瓶頸實際上並不在VM上。因此,JIT的優化計劃,最後沒有被列入該版本的PHP7特性中。不過,它很可能會在更後面的版本中實現,這點也非常值得我們期待哈。

(2)JIT效能的提升效果取決於專案的實際瓶頸

JIT在benchmark中有大幅度的提升,是因為程式碼量比較少,最終生成的ByteCodes也比較小,同時主要的開銷是在VM中。而應用在WordPress實際專案中並沒有明顯的效能提升,原因WordPress的程式碼量要比benchmark大得多,雖然JIT降低了VM的開銷,但是因為ByteCodes太大而又引起CPU快取命中下降和額外的記憶體開銷,最終變成沒有提升。
不同型別的專案會有不同的CPU開銷比例,也會得到不同的結果,脫離實際專案的效能測試,並不具有很好的代表性。

2. Zval的改變

PHP的各種型別的變數,其實,真正儲存的載體就是Zval,它特點是海納百川,有容乃大。從本質上看,它是C語言實現的一個結構體(struct)。對於寫PHP的同學,可以將它粗略理解為是一個類似array陣列的東西。
PHP5的Zval,記憶體占據24個位元組(截圖來自PPT):

PHP7的Zval,記憶體占據16個位元組(截圖來自PPT):

Zval從24個位元組下降到16個位元組,為什麼會下降呢,這裡需要補一點點的C語言基礎,輔助不熟悉C的同學理解。struct和union(聯合體)有點不同,Struct的每一個成員變數要各自佔據一塊獨立的記憶體空間,而union裡的成員變數是共用一塊記憶體空間(也就是說修改其中一個成員變數,公有空間就被修改了,其他成員變數的記錄也就沒有了)。因此,雖然成員變數看起來多了不少,但是實際佔據的記憶體空間卻下降了。

除此之外,還有被明顯改變的特性,部分簡單型別不再使用參照。

Zval結構圖(來源於PPT中):

圖中Zval的由2個64bits(1位元組=8bit,bit是「位」)組成,如果變數型別是long、bealoon這些長度不超過64bit的,則直接儲存到value中,就沒有下面的參照了。當變數型別是array、objec、string等超過64bit的,value儲存的就是一個指標,指向真實的儲存結構地址。

對於簡單的變數型別來說,Zval的儲存變得非常簡單和高效。

不需要參照的型別:NULL、Boolean、Long、Double
需要參照的型別:String、Array、Object、Resource、Reference

3. 內部型別zend_string

Zend_string是實際儲存字串的結構體,實際的內容會儲存在val(char,字元型)中,而val是一個char陣列,長度為1(方便成員變數佔位)。

結構體最後一個成員變數採用char陣列,而不是使用char*,這裡有一個小優化技巧,可以降低CPU的cache miss。
如果使用char陣列,當malloc申請上述結構體記憶體,是申請在同一片區域的,通常是長度是sizeof(_zend_string) + 實際char儲存空間。但是,如果使用char*,那個這個位置儲存的只是一個指標,真實的儲存又在另外一片獨立的記憶體區域內。

使用char[1]和char*的記憶體分配對比:

從邏輯實現的角度來看,兩者其實也沒有多大區別,效果很類似。而實際上,當這些記憶體塊被載入到CPU的中,就顯得非常不一樣。前者因為是連續分配在一起的同一塊記憶體,在CPU讀取時,通常都可以一同獲得(因為會在同一級快取中)。而後者,因為是兩塊記憶體的資料,CPU讀取第一塊記憶體的時候,很可能第二塊記憶體資料不在同一級快取中,使CPU不得不往L2(二級快取)以下尋找,甚至到記憶體區域查到想要的第二塊記憶體資料。這裡就會引起CPU Cache Miss,而兩者的耗時最高可以相差100倍。

另外,在字串複製的時候,採用參照賦值,zend_string可以避免的記憶體拷貝。

6. PHP陣列的變化(HashTable和Zend Array)

在編寫PHP程式過程中,使用最頻繁的型別莫過於陣列,PHP5的陣列採用HashTable實現。如果用比較粗略的概括方式來說,它算是一個支援雙向連結串列的HashTable,不僅支援通過陣列的key來做hash對映存取元素,也能通過foreach以存取雙向連結串列的方式遍歷陣列元素。
PHP5的HashTable(截圖來自於PPT):

這個圖看起來很複雜,各種指標跳來跳去,當我們通過key值存取一個元素內容的時候,有時需要3次的指標跳躍才能找對需要的內容。而最重要的一點,就在於這些陣列元素儲存,都是分散在各個不同的記憶體區域的。同理可得,在CPU讀取的時候,因為它們就很可能不在同一級快取中,會導致CPU不得不到下級快取甚至記憶體區域查詢,也就是引起CPU快取命中下降,進而增加更多的耗時。

PHP7的Zend Array(截圖來源於PPT):

新版本的陣列結構,非常簡潔,讓人眼前一亮。最大的特點是,整塊的陣列元素和hash對映表全部連線在一起,被分配在同一塊記憶體內。如果是遍歷一個整型的簡單型別陣列,效率會非常快,因為,陣列元素(Bucket)本身是連續分配在同一塊記憶體裡,並且,陣列元素的zval會把整型元素儲存在內部,也不再有指標外連,全部資料都儲存在當前記憶體區域內。當然,最重要的是,它能夠避免CPU Cache Miss(CPU快取命中率下降)。

Zend Array的變化:
(1) 陣列的value預設為zval。
(2) HashTable的大小從72下降到56位元組,減少22%。
(3) Buckets的大小從72下降到32位元組,減少50%。
(4) 陣列元素的Buckets的記憶體空間是一同分配的。
(5) 陣列元素的key(Bucket.key)指向zend_string。
(6) 陣列元素的value被嵌入到Bucket中。
(7) 降低CPU Cache Miss。

7. 函數呼叫機制(Function Calling Convention)

PHP7改進了函數的呼叫機制,通過優化引數傳遞的環節,減少了一些指令,提高執行效率。

PHP5的函數呼叫機制(截圖來自於PPT):

圖中,在vm棧中的指令send_val和recv引數的指令是相同,PHP7通過減少這兩條重複,來達到對函數呼叫機制的底層優化。

PHP7的函數呼叫機制(截圖來自於PPT):

8. 通過宏定義和行內函式(inline),讓編譯器提前完成部分工作

C語言的宏定義會被在預處理階段(編譯階段)執行,提前將部分工作完成,無需在程式執行時分配記憶體,能夠實現類似函數的功能,卻沒有函數呼叫的壓棧、彈棧開銷,效率會比較高。行內函式也類似,在預處理階段,將程式中的函數替換為函數體,真實執行的程式執行到這裡,就不會產生函數呼叫的開銷。

PHP7在這方面做了不少的優化,將不少需要在執行階段要執行的工作,放到了編譯階段。例如引數型別的判斷(Parameters Parsing),因為這裡涉及的都是固定的字元常數,因此,可以放到到編譯階段來完成,進而提升後續的執行效率。

例如處理傳遞引數型別的方式,從左邊的寫法,優化為右邊宏的寫法。

三、小結

鳥哥的PPT裡放出過一組對比資料,就是WordPress在PHP5.6執行100次會產生70億次的CPU指令執行數目,而在PHP7中只需要25億次,減少64.2%,這是一個令人震撼的資料。

在鳥哥的整個分享中,給我最深刻的一個觀點是:要注意細節,很多個細小的優化,一點點持續地積累,積少成多,最終匯聚為驚艷的成果。為山九仞,豈一日之功,我想大概也是這個道理。

毫無疑問,PHP7在效能方面實現跨越式的提升,如果能夠將這些成果應用在PHP的Web系統中,也許我們只需要更少的機器,就可以支撐起更高請求量的服務。PHP7正式版的發布,令人充滿無限憧憬。

推薦教學:《php視訊教學

以上就是學習PHP7的革新與效能優化的詳細內容,更多請關注TW511.COM其它相關文章!