BadooはPHP7に切り替えて100万ドルを節約しました

やった！ 数百のアプリケーションサーバーがPHP7に翻訳されており、とてもいい感じです。 私たちの知る限り、これはこの規模のPHP7プロジェクトへの2番目の移行です（Etsyの後）。 その過程で、PHP7バイトコードキャッシュシステムにいくつかの非常に不快なバグが見つかりましたが、修正されました。 そして今、乾杯！ -PHPコミュニティ全体にとって朗報です。PHP7は、実稼働環境で安定しており、メモリ消費量が大幅に削減され、パフォーマンスが大幅に向上しています。 以下では、PHP7に切り替えた方法、どのような困難に遭遇したか、どのように苦労したか、どのような結果を得たかを詳しく説明します。 しかし、簡単な紹介から始めましょう。



Webプロジェクトのボトルネックはデータベースであるという意見は、最も一般的な誤解の1つです。 適切に設計されたシステムはバランスが取れています-入力負荷が増加すると、システムのすべての部分が打撃を抑え、しきい値を超えると、すべてがスローダウンし始めます：ベースのドライブだけでなく、プロセッサとネットワーク部分の両方。 この現実では、アプリケーションクラスターのプロセッサパワーはほとんど最も重要な特性です。 多くのプロジェクトでは、このクラスターは数百または数千のサーバーで構成されているため、アプリケーションクラスターのプロセッサ負荷の「調整」は経済的に正当化されます（この場合は100万ドル）。



PHP Webアプリケーションのプロセッサは、高レベルの動的言語と同じくらい多くを「食べます」。 しかし、長年にわたって、PHP開発者は特別な悲しみ（および他のコミュニティからの最も強力な「トローリング」の機会）を経験しました-「正直な」JITまたは少なくともCやC ++などの言語のコンパイルされたテキストのジェネレーターがPHPにないこと。 メインプロジェクトのフレームワーク内でこのようなソリューションを提供できないコミュニティは、不快な傾向を引き起こしました。大規模なプレーヤーが独自のソリューションを考え出すようになりました。 したがって、FacebookにはHHVMが、VkontakteにはKPHPがあり、おそらく他の「クラフト」もありました。



幸いなことに、2015年、PHPを「成熟」させるための第一歩が踏み出されました。PHP7がリリースされました。 JITはPHP7には登場しませんでしたが、「エンジン」の変更の結果を過大評価することはほとんどありません：現在、多くのタスクで、JITがなくてもPHP7はHHVMに劣りません（たとえば、 LiteSpeedブログの ベンチマークとPHP7開発者のプレゼンテーションのベンチマークを参照 ）。 また、新しいPHP7アーキテクチャは、JITの追加を簡素化します。



Badooのプラットフォーム開発者は、過去数年間これらの情熱を注視しており、HHVMでパイロットプロジェクトを作成しましたが、より有望だと考えたためPHP7を待つことにしました。 そして最近、PHP7でBadooを開始しました！ 少なくともその規模のおかげで、これは壮大なプロジェクトでした。300万行を超えるPHPコードと60,000のテストがあります。 PHPアプリケーションをテストするための新しいフレームワーク（Go！AOPに類似したオープンソースで既にリリースされています）を開発し、100万ドルを節約しました。

HHVMの経験

PHP7に切り替える前に、しばらくの間、バックエンドを最適化する他の方法を探しました。 もちろん、HHVMで最初に「遊ぶ」ことを決めました。



調査に数週間を費やした後、非常にまともな結果が得られました。フレームワークでJITをウォームアップした後、速度とCPU使用率の向上は数百パーセントでした。



ただし、HHVMには不愉快な欠点がありました。

• 困難で遅い展開 。 デプロイするときは、JITキャッシュを確実にウォームアップする必要があります。 ウォームアップ時には、すべてが非常に低速に動作するため、マシンに実動トラフィックをロードしないでください。 並列クエリでウォームアップすることもお勧めしません。 要するに、大規模クラスターの加熱フェーズは迅速な操作ではありません。さらに、数百台のマシンの大規模クラスターで部分的にレイアウトする方法を学ぶ必要があります。 その結果、予測不可能な運用時間で、重要なアーキテクチャと展開手順が得られます。 そして、できるだけシンプルで迅速な展開を実現したいと考えています。開発文化の重要な部分は、1日に2つのリリースを計画し、ホットフィックスを迅速に「展開」する能力です。
• テストの不便。 ユニットテストでは、HHVMでは利用できないrunkit拡張を積極的に使用しました。 これについては後で詳しく説明しますが、わからない場合は、変数、クラス、メソッド、関数の動作をほとんどの方法でオンザフライで変更できる拡張機能です。これは、「内部」との非常に「ハードコア」な統合によって行われますPHP HHVMコアは、PHPコアとリモートでのみ類似しているため、これらの同じ「内部」は完全に異なります。 したがって、HHVMの上に独自にrunkitを実装するのは大変な作業です。拡張機能の性質により、HHVMがコードで正しく動作することを確認するために、何万ものテストを書き直す必要があります。 それは非現実的であるように思われました。 正直に言うと、これはいずれかのオプションの問題であり、PHP7に切り替えるときには、runkitを捨てるなど、何度もやり直す必要がありました。
• 互換性。 これは主に、PHP 5.5（ github.com/facebook/hhvm/blob/master/hphp/doc/inconsistencies、github.com/facebook/hhvm/issues?labels=php5+incompatibility&state=openを参照）との不完全な互換性です。拡張機能は既に作成されており、数十種類あります。 両方の非互換性は、プロジェクトの構造上の明らかな欠陥に起因しています。HHVMはコミュニティではなく、Facebook内の部門によって開発されています。 そのような場合、企業は、コミュニティや既に作成された大量のコードを振り返ることなく、内部のルールや標準を簡単に変更できます。 彼らがすべてをやり直し、リソースの問題を解決するのは簡単です。 したがって、同じ量のタスクを正常に処理するには、実装の初期段階とさらなるサポートの両方に匹敵する能力を持つリソースが必要です。 これはリスクが高く、潜在的に高価です-そのリスクを冒したくありませんでした。
• 見通し。 Facebookは優れたプログラマーを抱える大企業であるという事実にもかかわらず、HHVM開発部門がPHPコミュニティよりも強力になる可能性があることには大きな疑問がありました。 似たようなものがPHP内に現れるとすぐに、すべての自家製プロジェクトがゆっくりと、しかし確実に死に始めると思いました。

そして、PHP7を待ち始めました。



インタープリターの新しいバージョンへの移行は重要かつ困難なプロセスであるため、移行の明確な計画を作成して準備しました。 次の3つの準備段階で構成されていました。

• PHPを構築および展開するためのインフラストラクチャを変更し、作成した多くの拡張機能を適応させます。
• インフラストラクチャとテスト環境の変更。
• アプリケーションのPHPコードを変更します。

すべての段階について詳しく説明します。

カーネルと拡張機能の修正

私たちは、独自の、積極的に保守され、完成したPHPブランチを持っています。 公式リリースの前にBadooをPHP7に変換するプロジェクトを開始したため、各リリース候補の更新を受信できるようにするために、ツリー内でPHP7を定期的にリベースしてスムーズにリベースする必要がありました。 日常業務で使用するすべてのパッチとカスタマイズ（tech.badoo.com/open-source techsiteの「パッチ」セクションを参照）も、バージョン間で移植可能であり、正しく動作する必要がありました。



5.5および7.0では、すべての依存関係、拡張機能、PHPツリーのダウンロードとアセンブリを自動化しました。 これにより作業が簡素化されただけでなく、将来の優れた基盤も提供されました。バージョン7.1がリリースされると、すべての準備が整います。



拡張機能についても汗をかかなければなりませんでした。 約40の拡張機能をサポートしていますが、その半分以上が外部オープンソース拡張機能であり、改善されています。



可能な限り高速な移行のために、2つのプロセスを並行して実行することにしました。 1つ目は、最も重要な拡張機能を個別に書き換えることです：Blitzテンプレートエンジン、共有メモリのAPcuデータキャッシュ、Pinbaの統計情報の収集、および内部サービスを操作するためのいくつかのカスタム（結果として、約20の拡張機能）。

2つ目は、インフラストラクチャの重要ではない部分で使用されている拡張機能を積極的に取り除くことです。 11の拡張機能を簡単に取り除くことができました。



そしてもちろん、私たちはPHP7との互換性のために使用する主要なオープン拡張機能をサポートする人々と積極的にコミュニケーションを始めました（Xdebugを開発しているDerick Rethansに特に感謝します）。



さらに、PHP7への拡張機能の移植の技術的な詳細について詳しく説明します。



バージョン7では、PHP開発者が多くの内部APIを変更したため、拡張機能で多くのコードを編集する必要がありました。 最も重要な変更は次のとおりです。

• zval *→zval。 以前は、新しい変数を作成するときにzval構造が常に割り当てられ、スタックの構造が使用されるようになりました。
• char *-> zend_string。 PHP7はPHPコアでアグレッシブな文字列キャッシュを使用します。これが、新しいカーネルが文字列とその長さを格納するzend_string構造に普遍的に切り替えた理由です。
• 配列APIの変更。 zend_stringがキーとして使用されるようになりました;配列の実装では、二重リンクリストが通常の配列に置き換えられ、多くの小さな配列ではなく1つのブロックに割り当てられます。

これにより、小さなメモリ割り当ての数を大幅に削減し、その結果、PHPコアを数十パーセント高速化することができました。



これらすべての変更には、書き換える必要がなければ、すべての拡張機能を積極的に編集する必要があることに注意してください。 組み込みの拡張機能の場合、作成者に依存できる場合、開発は私たちだけが編集でき、多くの編集がありました：内部APIの変更により、コードの一部が書き直しやすくなりました。



残念ながら、ガベージコレクションを使用する新しい構造を導入すると、コードの実行速度が向上しますが、エンジン自体が複雑になり、問題を見つけることができなくなります。 それらの1つはOPcacheの問題でした。これは、キャッシュをクリアすると、キャッシュされたファイルのバイトコードが別のプロセスで使用できるときに破棄され、プロセスがクラッシュする原因となりました。 外観は次のようになりました。関数または定数の名前の行（zend_string）が突然崩れ、代わりにゴミが表示されます。



私たちは独自の設計の多くの拡張機能を使用しており、その多くは文字列を積極的に使用しているため、最初の疑いはそれらの文字列の誤用でした。 彼らは多くのテストを書き、多くの実験を行ったが、すべて役に立たなかった。 その結果、PHPコアのメイン開発者であるDmitry Stogovに助けを求める必要がありました。



まず、キャッシュがクリアされたかどうかを尋ねました。 実際、それぞれのケースでそうであることがわかりました。 問題はまだ私たちにあるのではなく、OPcacheにあることが明らかになりました。 問題を迅速に再現し、Dmitryは数日以内に修正しました。 PHPバージョン7.0.4に含まれていたこの修正がなければ、本番環境で安定して使用することは不可能でした！

テストインフラストラクチャの変更

Badooでのテストは私たちの特別な誇りです。 PHPコードを1日に2回実稼働環境にアップロードし、レイアウトごとに20〜50個のタスクを取得します（Gitで機能ブランチを使用し、JIRAと密接に統合された自動ビルドをビルドします）。 このようなスケジュールと、自動テストなしのタスクのボリュームを使用します。



今日、約50％のカバレッジで約6万のユニットテストがあり、クラウドで平均2〜3分で合格しています（これについてはHabréで既に説明しました ）。 単体テストに加えて、より高いレベルの自動テスト-統合およびシステムテスト、Webページのセレンテスト、モバイルアプリケーションのひょうたんテストを使用します。 この多様性により、コードの各特定バージョンの品質について迅速に結論付け、適切な決定を下すことができます。



インタープリターの新しいバージョンへの切り替えは基本的な変更です。 可能な限り多くの問題が発生する可能性があるため、すべてのテストが機能することが不可欠です。 それを、どのように、そしてなぜ行ったかを明確にするために、歴史に短いエクスカーションを取り入れ、当社のテスト開発の進化について話す必要があります。



多くの場合、製品のテストを考えている人は、実験のプロセス（および実装中の一部）で、コードの準備が整っていないことに遭遇します。 実際、開発者は自分のコードがテスト可能でなければならないことを覚えておく必要があります 。 アーキテクチャでは、テストされたコードを外部条件から分離するために、ユニットテストで外部依存関係の呼び出しとオブジェクトを置き換えることができます。 私はこの要件が人生を複雑にし、原則から多くのプログラマーがテストできるようにコードを書きたくないと言わなければなりません-課せられた制限は「良いコード」の他の値との不平等な闘争に入り、通常失われます。 そして、多くの場合、使用可能なコードの量がルールに従っていないと想像していたため、実験者はテストをより良い時期まで延期するか、小さなもので満足しようとするだけで、テストでカバーできるもののみをカバーします（結果として、テストは常に期待される結果を与えません）。



当社も例外ではありません。 また、プロジェクトの開始直後からテストを導入し始めました。 かなりの数行のコードがすでに書かれていますが、それは実稼働環境で十分に機能し、十分なお金をもたらしました。 推奨されるようにテストでカバーできるようにするためにこのコードをすべて書き換えると、長すぎて高価になります。



幸いなことに、その時点で、テストできないコードに関するほとんどの問題を解決できる優れたツール、runkitがすでにありました。 これはPHPの拡張機能であり、スクリプトの実行中にプログラムで使用されるメソッド、クラス、および関数を変更、削除、追加できます。 まだ多くのものがあるかもしれませんが、他の拡張機能は使用していません。 このツールは、HHVMを含むFacebookで現在働いているSarah Golemonによって、数年間（2005年から2008年まで）開発および保守されました。 2008年から現在まで、同プロジェクトは同胞Dmitry Zenovichによってサポートされています（彼はBegunとMail.Ruのテスト部門の責任者として働いていました）。 また、プロジェクトに少し「貢献」しました。



Runkit自体は非常に危険な拡張機能です。 これを使用すると、定数、関数、およびクラスを使用するスクリプトの実行中にそれらを直接変更できます。 実際、これは飛行中に飛行機を再構築できるツールです。 Runkitはその場でPHPの内部をクロールします。 runkitの1つの間違いまたは欠陥-飛行機が空中で美しく爆発したり、PHPがクラッシュしたり、メモリリークやその他の低レベルのデバッグを探すのに何時間も費やしたりします。 それでも、それは私たちにとって必要なツールでした。コードをオンザフライで変更し、必要なコードに置き換えるだけで、深刻な書き換えなしでプロジェクトにテストを実装することしかできません。



PHP7に切り替えると、runkitは大きな問題であることが判明しました。このバージョンのPHPはサポートされていませんでした。 新しいバージョンの開発を後援するオプションがありましたが、このパスは長期的には最も信頼できるものではありませんでした。 並行して、他のいくつかのオプションを検討しました。



有望なソリューションの1つは、runkitからuopzに切り替えることでした。 これは、同様の機能を備えたPHPの拡張機能でもあり、2014年4月に登場しました。 マンバの同僚から私たちに提供され、主に仕事のスピードについて非常に良いレビューを提供しました。 このプロジェクトは、First Beat Media（英国）のJoe Watkinsによってサポートされています。 このプロジェクトは、runkitと比較してより活発で有望に見えました。 しかし、残念ながら、すべてのテストをuopzに転送できませんでした。 致命的なエラーはどこか、どこかでセグメンテーション違反が発生しました-いくつかのレポートがありましたが、残念ながら動きはありません（詳細については、たとえばgithubのこのバグを参照）。 この場合、テストの書き換えを行うのは非常に高価であり、他の何かが明らかにされないという事実ではありません。



その結果、私たちにとって明らかな解決策を思い付きました：すでに多くのコードを書き直さなければならず、それでもrunkitやuopzのような外部プロジェクトに依存しているため、私たち自身で解決するには非常に高価または不可能な問題が絶えずありますすべての依存関係を最大限に削除するようにコードを書き換える必要はありませんか？ はい。HHVMまたは他の同様の製品に切り替えたい場合でも、このような問題は二度とありません。 そして、独自のフレームワークを取得しました。



システムはSoftMocksと呼ばれます。 ソフトという言葉は、システムが拡張機能を使用する代わりに純粋なPHPで実行されることを強調しています。 これはオープンソースプロジェクトであり、プラグインライブラリとして利用可能であり、 パブリックドメインにあります 。 SoftMocksは、PHPコア実装の機能とは関係なく、 Go！と同様にコードをその場で書き換えることで機能します。 ああ 。



テストコードは主に次のものを使用します。

1. クラスのメソッドの1つの実装の置換。
2. 関数の結果の置換。
3. グローバルまたはクラス定数の値を変更します。
4. クラスにメソッドを追加します。

これらの機能はすべて、runkitを使用して完全に実装されています。 コードを書き換えると、これが可能になりますが、注意が必要です。



Job Description SoftMocks-別の記事の資料。近いうちに作成します。 それまでの間、このシステムの動作の簡単な説明のみに制限しています。

• ユーザーコードは、書き換えラッパー関数を介して接続されます。 その後、すべてのincludeステートメントは自動的に再帰的にラッパーに置き換えられます。
• 置換の存在のチェックが各ユーザーメソッドの定義内に追加され、存在する場合、対応するコードが実行されます。 直接関数呼び出しは、ラッパーを介した呼び出しに置き換えられます-これにより、組み込み関数とユーザー定義関数の両方をインターセプトできます。
• コード内の定数の呼び出しも、ラッパーの呼び出しに動的に置き換えられます。
• SoftMocksはNikita PopovのPHP-Parserを使用します。 このライブラリはそれほど高速ではありません（解析はtoken_get_allの約15倍遅くなります）が、構文ツリーを走査するための便利なインターフェースを提供し、任意の複雑さの構文構造を扱うための便利なAPIを提供します。

PHP7への切り替え-タスクに戻りましょう。 プロジェクトでSoftMocksを使用し始めた後、手動で修復する必要がある約1000個のテストが残っていました。 最初は60,000のテストがあったため、これは良い結果と考えることができます。 runkitと比較した実行速度は低下していません。そのため、パフォーマンスの観点から、SoftMocksを使用しても深刻な損失はありません。 公平に言うと、uopzはさらに高速に動作するはずです。

ユーティリティとアプリケーションコード

多くの革新に加えて、PHP7には後方互換性があります。 問題の調査を始めた最初のことは、公式の移行ガイドを読むことです。 既存のコードを修正しないと、本番環境で致命的なエラーが発生し、ログには反映されないがアプリケーションのロジックが正しくない動作の変更が発生するリスクがあることがすぐに明らかになりました。



BadooはPHPコードのいくつかのリポジトリであり、最大のものには200万行を超えるコードが含まれています。 さらに、Webのビジネスロジックやモバイルアプリケーションのバックエンドからテストおよび計算ユーティリティまで、PHPで多くのことを実装しました。 さらに、Badooはすでに10年の歴史を持つプロジェクトであり、残念ながらPHP4の遺産がまだ存在しているという事実によって状況は複雑になりました。 したがって、「密接なピアリング」の方法は適用されません。 また、「ブラジルのシステム」は適用できません。つまり、本番環境にそのまま置いて、何が壊れるかを監視すると、あまりにも多くのユーザーのビジネスロジックが壊れるリスクが高まります。 そのため、互換性のない場所の検索を自動化する機会を探し始めました。



最初は開発者の間で最も人気のあるIDEを使用しようとしましたが、残念ながら、その時点ではPHP7の構文と機能をサポートしていなかったか、疑わしいほど少数の問題を検出し、明らかにコード内の危険な場所が見つかりませんでした。 少し調査した結果 、 php7marユーティリティを試してみることにしました。 これは、PHPで実装されたこのような単純な静的コードアナライザーです。 非常に使いやすく、非常に高速に動作し、結果はテキストファイルとして提供され、PHP7が必要です。 もちろん、このユーティリティは万能薬ではありません;コード内の特に「トリッキーな」場所の誤検知と省略の両方があります。 しかし、その助けによる問題の約90％が発見され、PHP7で動作するようにコードを準備するプロセスを大幅に加速および促進しました。



私たちにとって最も一般的で潜在的に危険な問題は次のとおりです。

• func_get_arg（）およびfunc_get_args（）関数の動作を変更します。 PHPの5番目のバージョンでは、これらの関数は転送時に関数の引数の値を返し、7番目のバージョンではfunc_get_args（）を呼び出したときに関数の引数の値を返しました。 したがって、関数内でfunc_get_args（）を呼び出す前に引数の引数が変更された場合、5番目のバージョンとは異なる動作をするリスクがあります。 これは、ログが空になり、アプリケーションのビジネスロジックが破損する可能性がある場合です。
• オブジェクトの変数、プロパティ、メソッドへの間接アクセス。 繰り返しますが、危険なのは、振る舞いが「静かに」変化する可能性があることです。 ドキュメントには、違いが正確に何であるかが十分に詳細に説明されています。
• 予約されたクラス名の使用。 PHP7では、クラス名としてbool、int、float、string、null、true、およびfalseを使用することができなくなりました。 はい、はい、Nullクラスがありました。 幸いなことに、このケースはエラーにつながるため、すでに簡単です。
• リンクを使用する潜在的に問題のあるforeachコンストラクトが多数見つかりました。 しかし、以前はforeach内の反復可能な配列を変更せず、内部ポインターに依存しないようにしていたため、5番目と7番目のバージョンではほとんどすべてが同じように動作しました。

非互換性の残りのケースは、非常にまれであるか（正規表現の 'e'修飾子など）、または単純な置換によって修正されました（たとえば、現在、すべてのコンストラクターは__construct（）と呼ばれるべきであり、クラス名の使用は禁止されています）。

しかし、コードの修正を開始する前に、互換性に必要な変更を行う開発者もいれば、PHP7と互換性のないコードを書き続ける開発者もいると考えました。 この問題を解決するために、可変のphp7 -lファイルで実行される各Gitリポジトリにpre-receiveフックを追加しました。 PHP7の構文に対してテストしました。 これは、非互換性に対する完全な保護を保証するものではありませんが、すでに多くの問題を排除しています。 それ以外の場合、開発者はもう少し注意する必要がありました。 さらに、PHP7の完全なテストスイートの定期的な実行を開始し、結果をPHP5の実行と比較しました。 同時に、開発者はPHP7の新機能を使用することを禁じられていました。 php5 -lで古いpre-receiveフックをオフにしませんでした。 これにより、ある時点で、インタープリターの7番目と5番目の両方のバージョンと互換性のあるコードを取得できました。 なぜこれが重要なのですか？ PHPコードの問題に加えて、新しいバージョンにアップグレードするときに、PHP7自体とその拡張機能に問題がある可能性があるためです（実際、上記のように、これらの問題に遭遇しました）。 そして、残念ながら、それらのすべてがテスト環境で再現されたわけではありません。その一部は、本番環境で大きな負荷がかかった場合にのみ見ることができました。

「起動」と結果

明らかに、任意の数のサーバーでPHPのバージョンを変更する簡単で迅速な方法が必要でした。 これを行うには、コード全体で、CLIインタープリターへのパスを/ local / phpに置き換えました。これは、/ local / php5または/ local / php7へのシンボリックリンクです。 したがって、サーバー上のPHPのバージョンを変更するには、リンクを変更する必要があり（操作はアトミックです-これはCLIスクリプトにとって重要です）、php5-fpmを停止し、php7-fpmを開始します。 nginxのphp-fpmに2つのアップストリームを持ち、異なるポートでphp5-fpmとphp7-fpmを実行することは可能ですが、nginxの構成を複雑にすることでこのオプションが気に入らなかったでしょう。



上記のすべてが完了した後、プリプロダクション環境でセレンテストを実行することができました。これにより、これまでに見られなかった多くの問題を検出することができました。 彼らは、PHPコード（たとえば、file_get_contents（ "php：// input"）を優先して古いグローバル変数$ HTTP_RAW_POST_DATAを放棄しなければならなかった）と拡張機能（さまざまな種類のセグメンテーションエラー）の両方に関係していました。



前の段階で検出された問題を修正し、ユニットテストの書き換えを完了したら（その間、インタープリターのいくつかのバグ（たとえば1つ ）も検出できました）、最終的にプロダクションの隔離を開始しました。 「検疫」とは、限られた数のサーバーで新しいバージョンのPHPを起動することです。 各大規模クラスター（Webおよびモバイルアプリケーションのバックエンド、クラウド）の1つのサーバーから開始し、エラーがなければ次第に数を増やしていきました。 PHP7に完全に移行した最初の主要なクラスターはクラウドでした。 この理由は、php-fpmが必要ないためです。 fpmが動作するのと同じクラスターが見つかるまで待たなければならず、Dmitry StogovはOPcacheの問題を修正しませんでした。 その後、すでにfpmクラスターを転送しています。



次に結果について。 要するに、彼らは印象的です。 以下は、私たちが所有する最大規模（263サーバー）のクラスター、つまりプラハデータセンターのモバイルアプリケーションのバックエンドでの応答時間、使用率、メモリ消費量、およびCPU使用率のグラフです。



応答時間の分布：





RUsage（CPU時間）：





メモリ使用量：





クラスター全体のCPU負荷（％）：





したがって、プロセッサー時間は2倍に短縮され、リクエストの処理に費やされた時間の一部がデータベースおよびデーモンと通信し、PHP7への移行ではこの部分は加速されないため、全体の応答時間は約40％改善されました。 さらに、クラスターの総負荷が50％を下回ったという事実によって、この効果はいくらか強化されています。これは、 ハイパースレッディングテクノロジーの機能の一部の機能を示しています。 大まかに言って、負荷が50％を超えると、HTコアが機能し始めます。これは物理コアほど「有用」ではありませんが、これは別の記事のトピックです。

メモリ消費量はボトルネックではありませんでしたが、約8倍減少しました！ そして最後に、機器を節約しました。同じ数のサーバーにかかる非常に大きな負荷に耐えることができるようになり、本質的に、購入とメンテナンスのコストを削減します。 他のクラスターの結果は若干異なりますが、OPcacheがないため、クラウドでのゲインがやや控えめです（CPUの約40％）。



どのくらいのお金を節約しましたか？ 数えましょう。 私たちのアプリケーションサーバークラスタは600以上のサーバーで構成されています。 CPU使用率を半分にすることで、約300台のサーバーを節約できます。 このような「鉄」の初期価格（それぞれ約4000ドル）と減価償却費を加えると、約100万ドルの節約に加えて、ホスティングで年間約10万ドルが得られます。 そして、それはクラウドも考慮しておらず、クラウドのパフォーマンスも向上しています。 これは素晴らしい結果だと信じています！



すでにPHP7に切り替えましたか？ コメントであなたの意見や質問を聞いてうれしいです。