介紹

我們成功的把我們的應(yīng)用遷移到了php7上面（數(shù)百臺機器的集群），而且運行的很好，據(jù)說我們是第二個把如此規(guī)模的應(yīng)用切換到php7的企業(yè)，在切 換的過程我們發(fā)現(xiàn)了一些php7字節(jié)碼緩存的bug，慶幸的是這些bug現(xiàn)在已經(jīng)被修復(fù)了，現(xiàn)在我們把這個激動人心的消息分享給所有的php社 區(qū)：php7現(xiàn)在已經(jīng)可以穩(wěn)定的運行在商用環(huán)境上，而且比以前更加節(jié)省內(nèi)存，性能也有的很大的提高。

下面我會詳細(xì)的介紹下我們是如何把應(yīng)用前移動php7的，我們在這中間遇到的問題及處理情況，還有最終的結(jié)果。但首先讓我們回頭看看一些更常見的問題：

Web項目的瓶頸在于數(shù)據(jù)庫持久化這是一個常見的誤解。一個設(shè)計良好的系統(tǒng)應(yīng)該是平衡的：當(dāng)訪問量增長時，由系統(tǒng)的各個部分分?jǐn)傔@些壓力，同樣的， 當(dāng)達到系統(tǒng)閥值時，系統(tǒng)的所有組件(不僅僅包括硬盤數(shù)據(jù)庫，還有處理器和網(wǎng)絡(luò))共同分?jǐn)倝毫??；谶@個事實，應(yīng)用集群的處理能力才應(yīng)該是最重要的因素。在 很多項目中，這種集群由數(shù)以百計甚至數(shù)以千計的服務(wù)器組成，這是因為花時間去調(diào)整集群的處理能力更加經(jīng)濟實益(我們因此節(jié)省一百多萬)。

PHP的Web應(yīng)用，處理器的消耗跟其他動態(tài)高級語言一樣多。但是PHP開發(fā)者面對著一個特別的障礙(這讓他們成為其他社區(qū)惡意攻擊的的受害者)： 缺少JIT，至少沒有一個像C/C++語言那樣的可編譯文本的生成器。PHP社區(qū)無力在核心項目框架上去實現(xiàn)一個類似的解決方案更是樹立了一種不良的風(fēng) 氣：主要的開發(fā)成員開始整合他們的解決方案，所以HHVM在Facebook上誕生了，KPHP在VKontakte上誕生，還有其他類似的方案。幸運地 是，在2015年，隨著PHP7的正式發(fā)布，PHP要開始”Grow up”啦。雖然還是沒有JIT，但很難去評定這些改變在”engine”中有多重要?，F(xiàn)在，盡管沒有JIT，PHP7可以跟HHVM相匹敵( Benchmarks from the LightSpeed blog  or PHP devs benchmarks)。新的PHP7體系架構(gòu)將會讓JIT的實現(xiàn)變得簡單。

在Badoo的平臺開發(fā)者已經(jīng)非常關(guān)注近些年出現(xiàn)的每一次問題，包括HHVM試點項目，但是我們還是決定等待很有前途的PHP7的到來?，F(xiàn)在我們啟 動了已經(jīng)基于PHP7的Baboo！這是一個史詩般的項目，擁有300多萬行的PHP代碼，并且經(jīng)歷了60000次的測試。我們?yōu)榱颂幚磉@些挑戰(zhàn)，提出了 一個新的PHP引用測試框架（當(dāng)然，也是開源的），并且在整個過程中節(jié)省了上百萬美元。

HHVM的試驗

在切換到PHP7之前，我們曾花了不少時間來尋找優(yōu)化后端的方法。當(dāng)然，第一步就是從HHVM下手。在試驗了幾周之后，我們獲得了值得關(guān)注的結(jié)果：在給框架中的JIT熱身之后，我們看到速度與CPU使用率上升了三倍。

另一方面，HHVM 被證實有一些嚴(yán)重的缺點：

• 部署困難而且慢。在部署過程中，你不得不首先啟動JIT-cache。當(dāng)機器啟動的時候，它不能負(fù)載產(chǎn)品流量，因為所有的事情進行的相當(dāng)慢。 HHVM 團隊同樣不推薦啟動并行請求。順便一提，大量聚類操作在啟動階段并不快速。此外，對于幾百個機器構(gòu)成的大集群你必須學(xué)習(xí)如何分批部署。這樣體系結(jié)構(gòu)和部署 過程相當(dāng)繁瑣，而且很難估算出所需要的時間。對于我們來說，部署應(yīng)該盡可能簡單快捷。我們的開發(fā)者將在同一天提供兩個開發(fā)版并且釋出許多補丁。

• 測試不便。我們非常依賴runkit擴展，但是它在HHVM中卻不可用。稍后我們將詳細(xì)介紹runkit，但是無需多言，它是一個能讓你幾乎隨心 所欲更改變量、類、方法、函數(shù)行為的擴展。這是通過一個抵達PHP核心的集成來實現(xiàn)的。HHVM引擎僅僅顯示了略微相像的PHP外觀，但是他們各自的核心 十分不同。鑒 于擴展的特定功能，在HHVM上獨立地實現(xiàn)runkit異常困難，而且我們不得不重寫數(shù)萬測試用例以確保HHVM和我們的代碼正確的工作。這看起來似乎不 值得。公平的說，我們以后在處理所有其他選項時也會遇到同樣的問題，而且我們在遷移到PHP7時仍然要重做許多事情包括擺脫runkit。但是以后會更 多。

• 兼容性。主要問題是不完全兼容PHP5.5(參考此處) ，并且不兼容現(xiàn)有的擴展(許多PHP5.5的)。這些所有的不兼容性導(dǎo)致了這個項目的明顯缺點: HHVM 不是被大社區(qū)開發(fā)的，相反只是Facebook的一個分支。在這種情況下公司很容易不參考社區(qū)就修改內(nèi)部規(guī)則和標(biāo)準(zhǔn)，而且大量的代碼包含其中。換句話說， 他們關(guān)起門來利用自己的資源解決了問題。因此，為了解決相似的問題，一個公司需要有Facebook一樣的資源不僅投入最初的實現(xiàn)同樣要投入后續(xù)支持。這 個提議不僅有風(fēng)險而且可能開銷很大，所以我們決定拒絕它。

• 潛力。盡管Facebook是一個大公司而且擁有無數(shù)頂尖程序員，我們?nèi)匀粦岩伤麄兊腍HVM開發(fā)者比整個PHP社區(qū)更強。我們猜想PHP的類似于HHVM的東西會很快出現(xiàn)，而前者將慢慢淡出我們的視野。

讓我們耐心等待PHP7。

切換到新版本的PHP7解釋器是一個重要和艱難的過程，我們準(zhǔn)備建立一個精確的計劃。這個計劃包括三個階段:

• 修改PHP構(gòu)建/部署的基礎(chǔ)設(shè)施和為大量的擴展調(diào)整現(xiàn)有的code

• 改變基礎(chǔ)設(shè)施和測試環(huán)境

• 修改PHP應(yīng)用程序的代碼。

我們稍后會給出這些這些階段的細(xì)節(jié)。

引擎和擴展的變化

在Badoo中， 我們有積極的支持和更新的PHP分支，我們在PHP7正式版release之前我們就已經(jīng)開始切換到php7了. 所以我們不得 不在我們的代碼樹經(jīng)常整合（rebase）PHP7上游的代碼，以便它來更新每個候選發(fā)布版。我們每天在工作中所用的補丁和自定義的code都需要在兩個 版本之間進行移植。

下載和構(gòu)建依賴庫、擴展程序、還包括PHP 5.5和7.0的構(gòu)建這些過程都是自動化的完成的。這不僅簡化了我們目前的工作，也預(yù)示著未來：在版本7.1出來時， 也許這一切（解析引擎和擴展等等）都已經(jīng)準(zhǔn)備到位了；

如上所述，我們將注意力轉(zhuǎn)向擴展。我們提供超過70種擴展，已經(jīng)比基于我們產(chǎn)品改寫的開源產(chǎn)品的半數(shù)還要多。

為了盡快能夠切換到它們，我們已經(jīng)決定開始同時進展兩件事情。第一個是逐一重寫各個關(guān)鍵擴展，包括blitz模板引擎，共享內(nèi)存/APCu中的數(shù)據(jù) 緩存，pinba數(shù)據(jù)分析采集器，以及其他內(nèi)部服務(wù)的自定義擴展（總的來說，我們已經(jīng)通過自己的力量完成大概20種擴展的重寫了）。

第二個是積極的清理僅僅在架構(gòu)中那些非關(guān)鍵部分使用的擴展，讓整個架構(gòu)更加簡潔。我們已經(jīng)迅速清理了11種擴展，都是那些無足輕重的！

另外，我們也同那些維護主要開放擴展的作者，一起積極地討論PHP7的兼容性（特別感謝xdebug的開發(fā)者Derick Rethans）。

我們遲點將進入更詳細(xì)的關(guān)于移植PHP7擴展的技術(shù)細(xì)節(jié)。

開發(fā)者已經(jīng)對PHP7中的內(nèi)部API做了大量修改，意味著我們可以修改大量的擴展代碼了。

下面是幾個最重要的變更：

• zval * -> zval。在早期的版本中，zval一直為新變量來分配內(nèi)存，但是現(xiàn)在引入了棧。

• char * -> zend_string。PHP7的引擎使用了更先進的字符串緩存機制。理由是，當(dāng)字符串與自身的長度同時存儲時，新的引擎可以將普通字符串完整的轉(zhuǎn)換為zend-string格式。

• 數(shù)組API的改變。zend_string作為key來使用，同時基于雙向鏈表的數(shù)組實現(xiàn)方法也被替代為普通的數(shù)組，需要強調(diào)的是，數(shù)組占用一個大的文件塊，而不是很多小的空間。

所有這些都可以從根本上減少小型內(nèi)存分配的數(shù)量，結(jié)果是，提高PHP引擎2%的速度。

我們能夠注意到，所有這些修改都至少需要改變所有的擴展（即使不是完全重寫）。雖然我們可以依賴內(nèi)置擴展的作者進行必要的修改，我們也當(dāng)然有責(zé)任自己修改他們，雖然工作量很大。由于內(nèi)部API的修改，使得只修改一些代碼段變得簡單。

不幸的是，引入使代碼執(zhí)行速度提升的垃圾回收機制讓引擎變得更加復(fù)雜并且變得更加難以定位問題。涉及到OpCache的問題。在緩存刷新期間，當(dāng)可 用于別的進程的已緩存的文件字節(jié)碼在此時損壞，就會導(dǎo)致崩潰。這就是它從外部看起來的樣子（zend_string)：使用方法名或者常量突然崩潰并且垃 圾就會出現(xiàn)。

鑒于我們使用了大量的內(nèi)部擴展，其中許多處理都是專門針對字符串的，我們懷疑這個問題與如何使用字符串在內(nèi)部擴展有關(guān)。我們寫了大量的測試，并進行了大量的實驗，但沒有得到我們預(yù)期的結(jié)果。最后，我們從PHP引擎開發(fā)人員 Dmitri Stogov 那里尋求了幫助。
他的第一個問題是“你有沒有清除緩存？”我們解釋說，事實上，我們每一次都在清除緩存。在這一點上，我們意識到這個問題并不在我們這里，而是 opcache。我們很快就轉(zhuǎn)載了這一案例，這有助于我們在幾天內(nèi)回復(fù)并解決這個問題。在7.0.4版本，這個修復(fù)沒有出來，就不可能使php7進入穩(wěn)定 產(chǎn)品。

更改測試基礎(chǔ)設(shè)施

我們?yōu)槲覀冊贐adoo上做測試感到特別驕傲。我們部署服務(wù)器的PHP代碼到產(chǎn)品環(huán)境，每天兩次，每次部署包含20-50份任務(wù)量（我們使用功能分 支Git和自動化緊JIRA集成版本）。鑒于這種時間表和任務(wù)量，我們沒有辦法不選擇自動測試。目前，我們大約有6萬個單元測試，約50％的覆蓋率，其運 行在云上，平均2-3分鐘（參見我們的文章了解更多）。除了單元測試，我們使用更高級別的自動測試，集成和系統(tǒng)測試，并為網(wǎng)頁做了Selenium測試，為手機客戶端做了Calabash測試。作為一個整體，這使我們能夠迅速達成與結(jié)論有關(guān)的代碼，每個具體版本的質(zhì)量，并應(yīng)用相應(yīng)的解決方案。

切換到新版本的解釋器是一個充滿潛在問題的重大變化，所以所有測試工作都是極其重要的。為了弄清我們到底做了什么，以及我們?nèi)绾卧O(shè)法做到這一點，讓我們來看看近幾年測試開發(fā)在Badoo上是如何演變的。

通常，當(dāng)我們開始考慮實施產(chǎn)品測試（或在某些情況下，已經(jīng)開始實施的話）時，在測試過程中我們會發(fā)現(xiàn)他們的代碼“并沒有達到測試階段”。出于這個原 因，在大多數(shù)情況下，開發(fā)者在寫代碼時要牢記，代碼的可測試性是很重要的。架構(gòu)師應(yīng)允許用單元測試去取代調(diào)用和外部依賴對象，以便代碼測試能與外部環(huán)境相 隔離。當(dāng)然，毫無疑問這是一個備受憎恨的要求，很多程序員認(rèn)為寫“可測試性”的代碼是完全不可接受的。他們認(rèn)為，這些限制完全不顧“優(yōu)秀代碼”的標(biāo)準(zhǔn)而且 通常不會取得成功。你能想象到，大量不按規(guī)則編寫的代碼，導(dǎo)致測試為了等“一個更好的時機”被延遲，或者通過運行小型測試來滿足并且在測試結(jié)果被推遲，或 實驗者為了使自己運行的小測試能夠通過，只做了能夠通過的那部分（也就是指測試沒有產(chǎn)生預(yù)期的結(jié)果）。
我并不是說我們公司是一個例外，從一開始，我們的項目也未執(zhí)行測試。因為依然有幾行代碼在生產(chǎn)過程中正常運作，帶來效益，所以正如文獻中建議的，如果只是為了運行測試重寫代碼將是一件愚蠢的事情。那將占用太長的時間，花費太多。

幸運的是我們有一個很棒的工具來解決“未測試代碼”的大問題——runkit。當(dāng)腳本在運行時，這個 PHP 擴展允許你對方法、類及函數(shù)進行增、刪、改的操作。此工具還有很多其它的功能但我們這里用不到它們。從 2005 年到 2008 年這個工具由 Sara Goleman（就職于 Facebook，有趣的是他在做 HHVM 方向的工作）開發(fā)和支持了多年。從 2008 年至今則由 Dmitri Zenovich （帶領(lǐng) Begun 和 Mail.ru 的測試部門）進行維護。我們也對這個項目做了些許貢獻。

同時，runkit 是一個非常危險的擴展，它允許你在使用它的腳本在運行的時候?qū)ΤＡ?、函?shù)及類進行修改。就像是一個允許你在飛行中重建飛機的工具。runkit 有直達 PHP “心臟”的權(quán)力，一個小錯誤或缺陷就能讓一切毀掉，導(dǎo)致 PHP 失敗或者你要用很多時間來查找內(nèi)存泄漏或做一些底層的調(diào)試。盡管如此，這個工具對于我們的測試還是必要的：不需要做大的重構(gòu)來完成項目測試只能在程序運行 的時候改變代碼來實現(xiàn)。

但是在切換到PHP7的時候發(fā)現(xiàn)runkit帶來了很大麻煩，因為它并不支持新的版本。我們當(dāng)然也可以在新版本中添加支持，但是從長遠(yuǎn)考慮，這看起來并不是最可靠的解決途徑。因此我們選擇了其他方法。

最適合的方法之一就是從runkit遷移到uopz。后者也是PHP的擴展，有著（與runkit）類似的功能性，于2014年正式推出。我在 Wamba的同事建議使用uopz，它將有很好的速度體驗。順便說一下uopz的維護者就是Joe Watkins（First Beat Media公司，英國）。不幸的是我們遷移到uopz的測試程序無論怎樣都無法成功運行。在某些地方總會發(fā)生致命的錯誤，出現(xiàn)在段錯誤中。我們提交了一些 報告，但很遺憾他們并沒有動作（e.g. https://github.com/krakjoe/uopz/issues/18）。為了解決這種困境而重寫測試程序的付出將會非常高昂，即使重寫了也很容易再次暴露出問題。

鑒于我們不得不重寫大量的代碼，而且還要依賴于runkit和uopz這種不知道有沒有問題的項目。很明顯,我們有了結(jié)論:我們應(yīng)該重寫我們的代 碼,而且要盡可能獨立。我們也承諾將盡一切可能來避免今后發(fā)生類似的問題，即使我們最終切換到HHVM或任何類似的產(chǎn)品。最終我們做出來了自己的框架。
我們的系統(tǒng)名為“SoftMocks”，“soft”意思是純php實現(xiàn),未使用擴展。該項目目前是一個開源的php庫。 SoftMocks不跟PHP引擎綁定，它是在運行中動態(tài)重寫代碼,功能類似于Go語言的AOP!框架。
以下功能在我們的代碼里已經(jīng)測試過：

1. override類方法

2. 覆蓋函數(shù)執(zhí)行結(jié)果

3. 更改全局常量或類常量的值

4. 類新增方法

所有這些東西都是用runkit實現(xiàn)的。動態(tài)修改代碼使項目臨時變更有了可能性。

我們沒有更多篇幅來討論關(guān)于SoftMocks的細(xì)節(jié)，但我們計劃寫一篇關(guān)于這個主題的文章。 這里我們給出一些關(guān)鍵點：

• 通過重寫中間函數(shù)來適配原有的用戶代碼。因此所有的包含操作將自動被中間函數(shù)重寫。

• 在每一個用戶定義的方法內(nèi)都增加了是否有重寫的檢查。如果存在重寫，相應(yīng)的重寫代碼就會被執(zhí)行。 原來直接函數(shù)調(diào)用的方式將被通過中間函數(shù)調(diào)用的方式所替換；這樣內(nèi)嵌函數(shù)和用戶自定義函數(shù)都能被執(zhí)行到。

• 對中間函數(shù)的動態(tài)調(diào)用將覆蓋代碼中變量的訪問權(quán)限

SoftMocks 可以和 Nikita Popov’s 的 PHP-Parser 配合： 這個庫不是很快（解析速度大概比token_get_all 慢15倍），但他的接口讓你繞過語法解析樹，并且包含了一個方便的API 用來處理不確定的語法結(jié)構(gòu)。

現(xiàn)在讓我們回到本文主題：切換到PHP 7.0版本。  當(dāng)我們通過SoftMocks把整個項切換過來后，我們依然有1000多個測試需要手動處理。你可以說這還不算太差的結(jié)果，和我們在開始時提到的 60000個測試相比的話。 和runkit相比，測試速度沒有下降，所以SoftMocks并沒有性能問題。 為了公平起見，我們認(rèn)為uopz 明顯的快很多。

盡管PHP7包含了許多新功能，但是仍然存在一些與老版本兼容的問題。首要的解決辦法是閱讀官方的移植文檔，之后我們會馬上明白如果不去修改現(xiàn)有代 碼，我們將會面對的不僅僅是在生產(chǎn)環(huán)境中遇到致命的未知錯誤并且由于升級后代碼的改變，我們無法在日志中查找到任何信息。這將會導(dǎo)致程序無法正常運行。

Badoo中有許多PHP代碼倉庫，其中最大的有超過2百萬行代碼。此外，我們還使用PHP實現(xiàn)了很多功能，從網(wǎng)站業(yè)務(wù)邏輯到手機應(yīng)用后段再到集成 測試和代碼部署。就目前來說，我們的情況很復(fù)雜，畢竟Badoo有很長的歷史，我們使用它已經(jīng)快十年了，最不幸的是仍然有采用PHP4的環(huán)境在運行。在 Badoo中，我們不推薦用‘just stare at it long enough’的方式來發(fā)現(xiàn)問題。一套所謂的’Brazilian’系統(tǒng)將代碼部署在生產(chǎn)環(huán)境，你需要等待直到它發(fā)生錯誤，這很容易引發(fā)大面積用戶在使用 中遇到業(yè)務(wù)上的錯誤，使其不明原因。綜上所訴，我們開始尋找一種方法能自動發(fā)現(xiàn)不兼容的地方。

最初，我們試圖用IDE的，這是開發(fā)者中很受歡迎，但不幸的是，他們要么不支持PHP7的語法和特征，要么沒有函數(shù)可以在代碼中找到所有的明顯的危險的地方，發(fā)現(xiàn)所有明顯危險的地方。進行了一些研究（如谷歌搜索）后，我們決定嘗試php7mar工具，它是用PHP實現(xiàn)一個靜態(tài)代碼分析儀。這PHP7工具使用起來非常簡單，很快工程，并為您提供了一個文本文件。當(dāng)然，它不是萬能的; 找特別是精心隱藏的問題點。盡管如此，該實用程序幫助我們鏟除約 90%的問題，大大加快和簡化了準(zhǔn)備 PHP7 的代碼的過程。

對我們來說，最常遇到的和潛在危險的問題是以下內(nèi)容：

• 在func_get_arg（）以及func_get_args的行為變化（）。在PHP的第5版本中，這些功能中的傳輸?shù)臅r刻返回參數(shù)值，但在 七個版本發(fā)生這種情況的時刻時func_get_args（）被調(diào)用。換句話說，如果函數(shù)內(nèi)func_get_args前參數(shù)變量的變化（）被調(diào)用，則該 代碼的行為可以由五個版本不同。同樣的事情發(fā)生時，應(yīng)用程序的業(yè)務(wù)邏輯壞了，但并沒有什么在日志中。

• 間接訪問對象變量，屬性和方法。并再次，危險在于，該行為可以更改“靜默”。對于那些尋找更多的信息，版本間的差異進行了詳細(xì)的描述在這里。

• 使用保留類名。在PHP7，可以不再使用布爾，整型，浮點，字符串，空，真假類名稱。，是的，我們有一個空的類。它的缺席實際上使事情變得更容易，但因為它常常導(dǎo)致錯誤。

• 使用引用許多潛在的問題的foreach結(jié)構(gòu)被發(fā)現(xiàn)了。由于我們試圖早不改變迭代數(shù)組中的foreach或雖在其內(nèi)部指針數(shù)，幾乎所有的人都表現(xiàn)在版本5和7相同。

剩余的不兼容性的情況下也很少遇到了 （像 ‘e’ 修飾符在正則表達式），或他們固定的一個簡單的替換 （例如，現(xiàn)在所有構(gòu)造函數(shù)應(yīng)該被命名為 __construct()。類名稱不允許使用）。
但是，我們即使在開始修復(fù)代碼之前，我們很擔(dān)心，一些開發(fā)商做一些必要的兼容性變化，其他人會繼續(xù)寫不符合 PHP7 的代碼。為了解決這一問題，我們把 pre-receive 鉤在已更改的文件 （換句話說，確保語法匹配 PHP7） 上執(zhí)行 php7-l 在每一個 git 存儲庫中。這并不能保證不會有任何兼容性問題，但它不會清除主機問題。在其他情況下，開發(fā)人員只是不得不變得更加專注。除此之外，我們開始在 PHP7 上運行的測試整個集并與 PHP5 的結(jié)果進行了比較。

此外，開發(fā)者不允許使用任何PHP7的新功能，例如，我們沒有禁止老版本的預(yù)接收鉤子 php5 -l。這允許我們讓代碼兼容PHP5和PHP7。為什么這個很重要？因為除了php代碼的問題之外，還有PHP7極其自身擴展的一些潛在的問題（這些都可 以證實）。并且不幸的是，不是所有的問題都可以在測試環(huán)境中重現(xiàn)出來；有一些我們只在產(chǎn)品的大負(fù)載時才見過。

實踐出真知

很明顯我們需要一種簡單快速的方法在任何數(shù)量以及類型的服務(wù)器上切換php版本。要啟用的話，所有指向CLI-interpreter的代碼路徑都 替換成了 /local/php，相應(yīng)的，是/local/php5或者/local/php7。這樣的話，要在服務(wù)器上改變php版本，需要改變鏈接（為cli腳 本操作設(shè)置原子操作是很重要的），停止php5-fpm，然后啟動php7-fpm。在nginx中，我們使用不同的端口為php-fpm和啟動 php5-fpm，php7-fom設(shè)置兩個不同的upstream，但我們不喜歡復(fù)雜的nginx配置。

在執(zhí)行完以上的清單后，我們接著在預(yù)發(fā)布環(huán)境運行Selenium 測試，這個階段暴露更多我們早期沒注意到的問題。這些問題涉及到PHP代碼（比如，我們不再使用過期全局變量$HTTP_RAW_POST_DATA，取 而代之是 file_get_contents(“php://input”)）以及擴展（這里存在各種不同類型的段錯誤）。
修復(fù)完早期發(fā)現(xiàn)的問題和重寫單元測試（這個過程中我們也發(fā)現(xiàn)若干隱藏在解析器的BUG比如這里）后，進入到我們稱為“隔離”發(fā)布階段。這個階段我們在一定數(shù)量的服務(wù)器上運行新版PHP。一開始我們在每個主要PHP集群（Web后臺，移動APP后臺，云平臺） 上只啟動一個服務(wù)，然后在沒有錯誤出現(xiàn)情況下，一點一點增加服務(wù)數(shù)量。云平臺是第一個完全切換到PHP7的大集群，因為這個集群沒有php-fpm需求。 fpm 集群必須等到我們找到或者Dmitri Stogov修復(fù)了OpCache問題。之后，我們也會將fpm集群切換到PHP7。

現(xiàn)在看下結(jié)果，簡單的說，他們是非常出色的。在這里，你能看到響應(yīng)時間圖，包括內(nèi)存消耗和我們的最大的集群（包括263服務(wù)器）的處理器的使用情況，以及在 Prague 數(shù)據(jù)中心的移動應(yīng)用后端的使用。

響應(yīng)時間分布：

RUsage (CPU 時間):

內(nèi)存使用:

CPU 加載 (%)-移動后臺集群

這一切到位，處理時間減少了一半，從而提高整體響應(yīng)時間約40%，由于一定量的請求處理時間是花在與數(shù)據(jù)庫和守護進程通信。從邏輯上講，我們不希望 這部分加快切換到php7。除此之外，由于超線程技術(shù)，集群的整體負(fù)載下降到50%以下，進一步促進了令人印象深刻的結(jié)果。廣義而言，當(dāng)負(fù)載增加超過 50%，HT-engines，而不是作為有用的物理引擎開始工作。但這已經(jīng)是另一篇文章的主題。此外，記憶的使用，這從來沒有一個瓶頸，我們，減少了大 約八倍以上！最后，我們節(jié)省了機器的數(shù)量。換句話說，服務(wù)器的數(shù)量可以承受更大的負(fù)載，從而降低獲取和維修設(shè)備的費用。在剩余的聚類結(jié)果相似，除云上的收 益是一個更溫和的（大約40%個CPU），由于opcache操作的減少。

來算算我們能節(jié)省多少費用呢？大致測算一下，一個Badoo應(yīng)用服務(wù)器集群大概包含600多臺服務(wù)器。如果cpu使用率減半，我們可以節(jié)省大約 300臺服務(wù)器?？紤]服務(wù)器的硬件成本和折舊，每臺大約4000美元?？偟乃阆聛砦覀兡芄?jié)省大約100萬美元，另加每年10萬的主機托管費。而且這還沒有 計算對服務(wù)云性能的提升帶來的價值，這個結(jié)果很令人振奮。

另外，您是否也考慮切換到PHP 7.0版本呢？ 我們很希望聽聽您關(guān)于此問題的觀點，而且非常愿意在下面的評論中回答您的疑問。

Badoo 團隊