iThome
在1995年Rasmus Lerdorf發明了PHP,20年後它成為世界上廣泛使用的網頁語言之一,同時也是臺灣許多網頁開發的程式語言。PHP之父Rasmus Lerdorf來臺參加Modern Web大會時,介紹PHP 7許多新特色,效能是最大的變革,甚至在特定應用上的效能可以比前一代提升了一倍,媲美使用了臉書PHP效能優化技術HHVM後的效能表現。Rasmus Lerdorf也在會後揭露了更多PHP 7效能超快的關鍵。
Q 你開發PHP 7時,是以HHVM為競爭對手嗎?
A 沒錯。臉書開發出了HHVM來優化自家PHP網站的效能,讓大家看到了PHP也可以講究效能。但HHVM只適用於特定用途,如臉書網站上的常見應用,而非通用性的優化技術。HHVM它永遠不會支援Windows或者嵌入式系統, 也無法在ARM架構下編譯。
過去PHP重視功能完整性,效能表現經常遭人詬病,而臉書自行開發的PHP版本HHVM,讓大家開始重視PHP的效能表現。不過,開發者還是在功能完整的傳統PHP,及超高效能的HHVM間抉擇。PHP 7兼顧功能及效能,未來使用者不需要在兩者之間取捨。
Q 你如何讓PHP 7的速度可比擬HHVM?
A 先是從機械指令下手,不論我們做什麼樣的事情,都會從zval開始。zval是用來儲存變數的PHP內部的C語言基礎資料結構,不論是整數、長整數、雙精度浮點數、浮點數、陣列及物件都會儲存在zval數值。所有的東西都建立在這個基本架構之上。
zval在PHP 5中所用的容量大小是76 位元組,但到了PHP 7,zval容量縮減為52位元組,意味建立PHP 7的基本資料結構縮減了24 位元組,因為每次要搬動的資料單位變小了,所以可以執行得更快,這是其中一個關鍵改變。但我們也仔細檢視PHP的結構,看哪些地方還可以更加精簡,例如精簡需要搬動的記憶體、優化執行一項請求需耗費的記憶體等,並把變數從Stack移到Heap。同時,也重新檢視編譯器如何編譯程式碼,如PHP是否善用GGC編譯器等。但其實不是單一項重大變革讓PHP 7跑得更快,若只將zval縮小24位元組,是無法讓PHP 7的速度翻一倍,更重要的是得仔細檢查數百個小細節,逐一思考是否有方法能夠優化每個環節,才能讓PHP運作得更順利。透過這種方法,PHP 7才有如此的效能表現。
Q PHP 7中有加入JIT功能嗎?
A 目前PHP 7還未加入JIT功能。JIT特別適用重複使用同樣記憶體位址的程式碼,在這方面JIT真的可以讓效能加速許多。舉例來說,如果第一次在PHP腳本上用命令介面運作HHVM,它的效能表現非常不好,得多跑幾次,直到JIT開始學習到特定運作模式後,HHVM的效能才會快起來。
我們已開始在PHP中加入JIT,不過還不夠成熟,得好好思考如何在開發PHP過程中導入JIT的概念。在開發中過程中導入JIT的思維很困難,如何讓JIT實際能改善效能則是難上加難,而臉書投入大量的人力去開發JIT,讓大家看到JIT的能耐。
我很期待未來PHP程式庫加入JIT後,在7.1或7.2版時能更好的表現。
Q 這表示大型網站的執行效能可以更好囉?
A 對,效能提高一倍,可以用更少的伺服器來提供同樣的服務能量,越大型的網站可以節省越多伺服器來節省成本。另一個對大型網站有幫助的新特色是,PHP 7能有效減少網路延遲(Latency)時間。當延遲時間超過200毫秒時,網頁就顯得有點慢。如果超過800毫秒,這個網站就像不能運作一樣。而PHP 7現在可以做到30毫秒就回傳一個網頁,即使差一點的100毫秒也算表現很好。
PHP 7可以讓網站往微服務(Microservice)的方向前進。不像過去的單套式(monolithic)網站程式,現在PHP 7更能應付分散式架構的需求。當網站由大量微服務組成時,縮短網路延遲時間就變得很重要,尤其當這些服務間有相依性時,如果一個服務回應的時間過久,就會拖累整體網站的速度。
Q 可以說PHP 7是為微服務所設計的嗎?
A 是,我的確是這樣設計新版PHP。PHP原本就對像微服務這類用途的架構一直都很在行,對PHP來說,每一個要求都是獨立、唯一並且無狀態(stateless)的,這也是PHP獨特之處。使用者可以任意的擴張規模,因為PHP不是應用程式伺服器,不會記住使用者先前的請求。
Q 就你觀察,微服務會如何改變傳統網站結構?
A 我不認為會改變多少,即便是單套式網站應用程式,仍然需要一些模組化的元件。以使用者認證為例,當用戶輸入密碼後,系統會檢驗是否為正確,如果正確就會進行後續的動作,而這其實這串流程已經內含微服務的概念了。傳統作法會建立單套式HTML網頁,列出一串判斷程序,來執行各種不同的動作。微服務不會改變人們如何寫程式,而會改變網站背後的架構,但對前端或應用工程師來說,做的事情還是一樣。
Q 微服務和服務導向架構(SOA)有什麼差別?
A 架構上來說是一模一樣的。不過,這要看你用什麼角度來比較這兩者,微服務可以定義的跟服務導向架構一模一樣,或者你可以從學術角度來比較差異。不過,對我來說是同一件事,微服務所提供的就是服務導向架構。不論是微服務架構或服務導向架構都試圖所有服務分開並且模組化,這兩者都跟單套式架構的邏輯完全相反。不過,使用者不在意網站怎麼運作,只要送出請求可以得到回覆就好。
Q 微服務架構是否更適合用於雲端原生應用?
A 其實,這些名詞變來變去,都還是講一樣的概念,那就是建立模組化的架構。這樣做的優點在於讓服務具有可替換性,使用者只需要關心送出的請求有沒有被傳回,至於用什麼程式語言實作出來不是很重要。但,若網站不是採用服務導向架構,那用什麼程式語言寫就有關係了,因為不同的服務都共用一個語言程式庫,程式語言的設計或效能就會有影響。
對我來說,服務導向架構這個說法比較合邏輯,因為它把不同的服務模組化。不過,我很早就開始這樣做了,只是現在人們將這樣的架構取了新名字,不管大家叫它服務導向架構、微服務或是其他名字。
早在2006年時,我就寫一篇文章批評開發框架。因為當時許多開發框架是單套式結構,缺乏徹底模組化的概念,這種通用式架構的開發框架,將所有東西集中到一個前端控制器,跟分散式的微服務架構思維南轅北轍。我很不喜歡這種開發框架的設計邏輯。
熱門新聞
2024-10-23
2024-10-30
2024-10-30