こんにちは、Habr！ 2年前、PHP 7.0に切り替えて100万ドルを節約した方法について書きました 。 負荷プロファイルでは、新しいバージョンはCPU使用率が2倍効率的であることが判明しました。これは、移行が約300になり始めた後、約600のサーバーにサービスを提供するために使用した負荷です。 その結果、2年間、予備の能力がありました。

しかし、Badooは成長しています。 アクティブユーザーの数は常に増加しています。 ユーザーがアプリケーションでより多くの時間を費やしているおかげで、機能を改善および開発しています。 そしてこれは、リクエストの数に反映され、2年で2〜2.5倍に増加しました。

リクエストの2倍以上の増加によって2倍のパフォーマンスの向上が平準化される状況にあり、クラスターの限界に再び近づき始めました。 PHPのコアでは、有用な最適化 （JIT、プリロード）が再び期待されますが、それらはPHP 7.4でのみ計画されており、このバージョンは1年以内にリリースされます。 したがって、移行のトリックを今すぐ繰り返すことはできません。アプリケーションコード自体を最適化する必要があります。

カットの下で、そのようなタスクにどのようにアプローチするか、どのツールを使用するかを説明し、私たちが適用し、私たちの時代に役立った最適化、アイデア、アプローチの例を示します。

最適化する理由

パフォーマンスの問題を解決する最も簡単で明白な方法は、鉄を追加することです。 コードを同じサーバーで実行する場合、もう1つ追加するとクラスターのパフォーマンスが2倍になります。 これらのコストを開発者の作業時間に振り替えて、自分自身に問いかけます。最適化により、この期間中に生産性を2倍に高めることができますか？ おそらくそうかもしれませんが、そうではないかもしれません。それは、システムがすでに最適に動作していることと、開発者がどれだけ優れているかによって異なります。 一方、購入したサーバーは会社の所有物のままであり、費やした時間は返されません。

少量の場合、正しい解決策は鉄の追加であることが多いことがわかります。

しかし、状況を見てみましょう。 PHP 7.0への切り替えによる利益が、アクティビティの増加とユーザー数によって相殺された後、PHPアプリケーションへのリクエストを処理する600台のサーバーが再びあります。 容量を1.5倍にするには、300台のサーバーを追加する必要があります。

サーバーの平均コスト-4,000ドルを計算に使用します。 300 * 4000 = $ 1,200,000-容量を1.5倍増やすコスト。

つまり、私たちの状況では、システムの最適化にかなりの時間を費やすことができ、鉄を購入するよりも収益性が高くなります。

キャパシティプランニング

何かを行う前に、問題があるかどうかを理解することが重要です。 そうでない場合は、いつ表示されるかを予測する価値があります。 このプロセスは容量計画と呼ばれます。

パフォーマンスの問題の具体的な指標は、応答時間です。 実際、CPU（または他のリソース）が6％または146％でロードされているかどうかは関係ありません。クライアントが満足な時間内に必要な品質のサービスを受信する場合、すべてが正常に機能します。

応答時間に注目することの欠点は、通常、問題がすでに現れたときにのみ増加することです。 まだない場合は、その外観を予測することは困難です。 さらに、応答時間はすべての要因（ブレーキサービス、ネットワーク、ドライブなど）の影響の結果を反映しており、問題の原因を理解することはできません。

私たちの場合、通常はCPUがボトルネックであるため、クラスターのサイズとパフォーマンスを計画するときは、主にその使用に関連するメトリックに注意を払います。 すべてのマシンからCPU使用率を収集し、平均値、中央値、75パーセンタイルおよび95パーセンタイルでグラフを作成します。


クラスターマシンのCPU使用率（パーセント）：平均、中央値、パーセンタイル

私たちのクラスターには何百ものマシンがあり、長年そこに追加されてきました。 構成とパフォーマンスが異なります（クラスターは同種ではありません）。 バランサーはこれを考慮に入れ（ 記事とビデオ ）、能力に応じてマシンをロードします。 このプロセスを制御するために、最大負荷マシンと最小負荷マシンのスケジュールも用意されています。


最も負荷の少ないクラスターマシン

これらのグラフ（または単にtopコマンドの出力）を見て、CPU負荷が50％の場合、負荷が2倍に増加する余地があると考えるかもしれません。 しかし、実際にはこれは通常そうではありません。 そして、ここに理由があります。

ハイパースレッディング

ハイパートレッドのないシングルコアを想像してください。 1つのCPUバウンドスレッドでロードします。 上部に100％の読み込みが表示されます。

次に、このカーネルでハイパーリーディングをオンにして、まったく同じ方法でロードします。 上部にはすでに2つの論理コアがあり、合計負荷は50％（通常は1％で、もう1つは100％）です。


CPU使用率：トップデータと実際に発生すること

プロセッサが50％しかロードされていないかのように。 しかし、物理的に追加の空きコアは現れませんでした。 ハイパートレッドを使用すると、1つの物理コアで一度に複数のプロセスを実行できる場合があります。 しかし、これは一般的な状況でパフォーマンスを2倍にすることにはほど遠いですが、CPU使用率グラフでは50％から100％の半分のリソースに見えます。

これは、ハイパートレッドが有効になっている場合、CPU使用率の50％を超えると、以前と同じように成長しないことを意味します。

実証するためにこのコードを作成しました（これは何らかの合成的なケースであり、実際には結果が異なります）。


ラップトップには2つの物理コアがあります。 異なる数の並列Cプロセスでパフォーマンスを測定するには、異なる入力データでこのコードを実行します。


打ち上げの結果をプロットします。

並列プロセスの数に応じたスクリプトのパフォーマンス

あなたが注意を払うことができるもの：

• C = 1とC = 2はHT = onとHT = offで予想どおり同じであり、物理コアを追加するとパフォーマンスが2倍になります。
  

• C = 3では、HTの利点が顕著になります。HT= onの場合、追加のパフォーマンスを得ることができましたが、C = 3以降のHT = offの場合、予想どおりゆっくりと減少し始めます。
  

• C = 4では、HTのすべての利点が見られます。 さらに30％の追加のパフォーマンスを絞ることができましたが、現時点でC = 2と比較すると、当社のCPU使用率は50％から100％に増加しました。
  

CPU負荷の上位50％で見ると、このスクリプトを実行すると8,065 Mhash /秒になり、100％-10,511 Mhash /秒になります。 これは、トップの約50％で最大システムパフォーマンスの8.065 / 10.511〜77％を取得し、実際には約100％が予備に残っていることを意味します-77％= 23％、50％ではないようです。

この事実は、計画時に考慮する必要があります。


デモスクリプトのCPU使用率：上位データと実際に起こること

トラフィックの不整合

ハイパートレッドに加えて、計画は、時刻、曜日、季節、その他の頻度に応じてトラフィックの不均一性を複雑にします。 たとえば、私たちにとって、ピークは日曜日の夕方です。


1秒あたりのリクエスト数、日曜日の夕方のピーク

要求の数が常に明確に変化するとは限りません。 たとえば、ユーザーは何らかの方法で他のユーザーと対話できます。一部のユーザーのアクティビティは、他のユーザーへのプッシュ/電子メールを生成し、プロセスに関与させることができます。 これには、トラフィックを増やすプロモーションキャンペーンが追加されており、そのための準備も必要です。

これはすべて、計画時に考慮することも重要です。たとえば、ピーク日までに傾向を構築し、ピーク成長の可能性のある非線形性を念頭に置いてください。

プロファイリングおよび測定ツール

パフォーマンスの問題があることがわかったとします。これはデータベース/サービス/ものではないことを理解し、コードを最適化することにしました。 これを行うには、まず、プロファイラーまたはいくつかのツールを使用してボトルネックを検出し、最適化の結果を確認する必要があります。

残念ながら、今日のPHPには、優れた汎用ツールはありません。

性能

perfは、Linuxカーネルに組み込まれたプロファイリングツールです。 別のプロセスによって起動されるサンプリングプロファイラーであるため、プロファイリングされるプログラムにオーバーヘッドが直接追加されることはありません。 間接的に追加されたオーバーヘッドは均一に「スミア」されているため、測定値が歪むことはありません。

すべての利点について、perfはコンパイルされたコードとJITでのみ機能し、「仮想マシンの下で」実行されるコードでは機能しません。 そのため、PHPコード自体のプロファイルを作成することはできませんが、さまざまなPHP拡張機能を含むPHPの内部での動作や、使用されるリソースの量を明確に確認できます。

たとえば、perfを使用すると、圧縮場所など、いくつかのボトルネックが見つかりました。これについては、後で説明します。

例：

perf record --call-graph dwarf,65528 -F 99 -p $(pgrep php-cgi | paste -sd "," -) -- sleep 20
perf report

（プロセスとperfが異なるユーザーで実行される場合、perfはsudoで実行する必要があります）。


PHP-FPMのパフォーマンスレポート出力の例

XHProfおよびXHProfアグリゲーター

XHProfは、関数/メソッドへのすべての呼び出しにタイマーを配置するPHPの拡張機能であり、取得した結果を視覚化するツールも含まれています。 perfとは異なり、PHPコードの条件で操作できます（ただし、拡張機能で発生することは確認できません）。

欠点には次の2つがあります。

• すべての測定値は単一のリクエストのフレームワーク内で収集されるため、全体としての画像に関する情報は提供されません。
  
• たとえば、Xdebugを使用する場合ほど大きくはありませんが 、オーバーヘッドが大きくなり、場合によっては結果が大きく歪むことがあります（関数が呼び出される頻度が高く、単純であるほど、歪みが大きくなります）。
  

最後のポイントを示す例は次のとおりです。

 function child1() { return 1; } function child2() { return 2; } function parent1() { child1(); child2(); return; } for ($i = 0; $i < 1000000; $i++) { parent1(); } 

デモのXHProf出力：parent1は、child1とchild2の合計よりも桁違いに大きい

parent1（）は、child1（）+ child2（）の500倍以上実行されたことがわかりますが、実際には、main（）およびparent1（）と同じように、これらの数はほぼ等しいはずです。

最後の欠点と戦うのが難しい場合、最初の欠点と戦うために、XHProfのアドオンを作成しました。これは、異なるリクエストのプロファイルを集約し、集約されたデータを視覚化します。

XHProfに加えて、他の多くのあまり知られていないプロファイラーが同様の原理に取り組んでいます。 それらには同様の利点と欠点があります。

ピンバ

ピンバを使用すると、スクリプト（アクション）およびプリセットタイマーによってパフォーマンスを監視できます。 スクリプトのコンテキストでのすべての測定はそのまま使用できるため、追加の手順は必要ありません。 Getrusageはスクリプトとタイマーごとに実行されるため、特定のコードに費やされたプロセッサー時間を正確に把握できます（サンプリングプロファイラーとは異なり、この時間はネットワークやディスクなどになります）。 ピンバは、履歴データを保存し、一般的なクエリと特定の種類のクエリの両方で画像を取得するのに最適です。


ピンバから派生したすべてのスクリプトの一般的なルーズ

欠点には、スクリプト全体ではなく、コードの特定のセクションをプロファイルするタイマーをコード内に事前に配置する必要があるという事実と、データを歪める可能性のあるオーバーヘッドの存在が含まれます（XHProfなど）。

phpspy

phpspyは比較的新しいプロジェクトで（GitHubでの最初のコミットは半年前でした）、有望そうなので、私たちはそれを注意深く監視しています。

ユーザーの観点から見ると、phpspyはperfに似ています。並列プロセスが起動し、PHPプロセスのメモリ部分を定期的にコピー、解析し、そこからスタックトレースやその他のデータを受け取ります。 これはかなり具体的な方法で行われます。 オーバーヘッドを最小限に抑えるため、phpspyはPHPプロセスを停止せず、実行中にメモリを直接コピーします。 これにより、プロファイラーが一貫性のない状態になる可能性があり、スタックトレースが破損する可能性があります。 しかし、phpspyはこれを検出でき、そのようなデータを破棄します。

将来的には、このツールを使用して、画像全体のデータと特定の種類のクエリのプロファイルの両方を収集できるようになります。

比較表

ツール間の違いを構造化するために、ピボットテーブルを作成しましょう。


プロファイラーの主な機能の比較
炎グラフ

最適化とアプローチ

これらのツールを使用して、リソースのパフォーマンスと使用状況を常に監視しています。 それらが不当に使用される場合、またはしきい値に近づいている場合（CPUの場合、成長の場合に時間の余裕を持たせるために経験的に55％の値を選択しました）、上で書いたように、問題の解決策の1つは最適化です。

さて、PHP 7.0の場合のように、最適化が既に他の誰かによって行われている場合、このバージョンは以前のものよりもはるかに生産的であることが判明しました。 私たちは通常、最新バージョンのPHPへのタイムリーな更新を含む、最新のテクノロジーとツールの使用を試みます。 公開 ベンチマークによると、PHP 7.2はPHP 7.1より5〜12％高速です。 しかし、悲しいかな、この移行ははるかに少ないものでした。

常に、膨大な数の最適化を実装してきました。 残念ながら、それらのほとんどはビジネスロジックに強く関連しています。 私たちだけでなく、私たちのコードの外部で使用できるアイデアやアプローチに関連する可能性のあるものについてお話します。

Zlib圧縮=> zstd

大きなmemkeyキーには圧縮を使用します。 これにより、圧縮/解凍のCPUコストが増加するため、ストレージに使用するメモリを3〜4倍削減できます。 これにはzlibを使用しました（memekesを操作するための拡張機能は、PHPに付属する拡張機能とは異なりますが、公式のものも zlibを使用します ）。

パフォーマンスでは、生産は次のようなものでした。

+ 4.03% 0.22% php-cgi libz.so.1.2.11 [.] inflate
+ 3.38% 0.00% php-cgi libz.so.1.2.11 [.] deflate

時間の7-8％が圧縮/解凍に費やされました。

さまざまなレベルと圧縮アルゴリズムをテストすることにしました。 zstdはデータに対してほぼ10倍速く実行され、その場所で約1.1倍失われることが判明しました。 アルゴリズムをかなり単純に変更することで、約7.5％のCPUを節約できました（これは、ボリューム上では約45台のサーバーに相当します）。

異なる圧縮アルゴリズムのパフォーマンスの比率は、入力データによって大きく異なる可能性があることを理解することが重要です。 さまざまな比較がありますが、最も正確には、実際の例を使用してのみ推定できます。

IS_ARRAY_IMMUTABLEはめったに変更されないデータのリポジトリとして

実際のタスクで作業する場合、頻繁に必要なデータを扱う必要がありますが、同時に変更することはほとんどなく、サイズも制限されています。 同様のデータがたくさんあります 。良い例は、 分割テストの構成です。 ユーザーが特定のテストの条件に該当するかどうかを確認し、これに応じて、ユーザーに実験的または通常の機能を示します（これはほぼ各リクエスト中に発生します）。 他のプロジェクトでは、国や都市、言語、カテゴリ、ブランドなど、構成やさまざまなディレクトリがその例になります。

そのようなデータは頻繁に要求されるため、その受信はアプリケーション自体とこのデータが保存されているサービスの両方に顕著な追加の負担を引き起こす可能性があります。 後者の問題は、たとえば、PHP-FPMを実行している同じマシンのメモリをストレージとして使用するAPCuを使用して解決できます。 しかし、それでも：

• シリアル化/逆シリアル化のコストが発生します。
  
• 変更する際に何らかの方法でデータを無効にする必要があります。
  
• PHPで変数にアクセスする場合と比べて、オーバーヘッドが発生します。
  

PHP 7.0では、 IS_ARRAY_IMMUTABLE最適化が導入されています。 コンパイル時にすべての要素がわかっている配列を宣言すると、その配列は一度処理されてOPCacheメモリに配置されます。PHP-FPMワーカーは、変更を試みる前に時間を費やすことなくこの共有メモリを参照します。 また、このような配列のインクルードには、サイズに関係なく一定の時間がかかります（通常は約1マイクロ秒）。

比較のため：includeおよびapcu_fetchを介して10,000個の要素の配列を取得する時間の例：

 $t0 = microtime(true); $a = include 'test-incl-1.php'; $t1 = microtime(true); printf("include (%d): %d microsec\n", count($a), ($t1-$t0) * 1e6); $t0 = microtime(true); $a = apcu_fetch('a'); $t1 = microtime(true); printf("apcu_fetch (%d): %d microsec\n", count($a), ($t1-$t0) * 1e6); //include (10000): 1 microsec //apcu_fetch (10000): 792 microsec 

生成されたオペコードを見ると、この最適化が適用されているかどうかを確認するのは非常に簡単です。

 $ cat immutable.php <?php return [ 'key1' => 'val1', 'key2' => 'val2', 'key3' => 'val3', ]; $ cat mutable.php <?php return [ 'key1' => \SomeClass::CONST_1, 'key2' => 'val2', 'key3' => 'val3', ]; $ php -d opcache.enable=1 -d opcache.enable_cli=1 -d opcache.opt_debug_level=0x20000 immutable.php $_main: ; (lines=1, args=0, vars=0, tmps=0) ; (after optimizer) ; /home/ubuntu/immutable.php:1-8 L0 (4): RETURN array(...) $ php -d opcache.enable_cli=1 -d opcache.opt_debug_level=0x20000 mutable.php $_main: ; (lines=5, args=0, vars=0, tmps=2) ; (after optimizer) ; /home/ubuntu/mutable.php:1-8 L0 (4): T1 = FETCH_CLASS_CONSTANT string("SomeClass") string("CONST_1") L1 (4): T0 = INIT_ARRAY 3 T1 string("key1") L2 (5): T0 = ADD_ARRAY_ELEMENT string("val2") string("key2") L3 (6): T0 = ADD_ARRAY_ELEMENT string("val3") string("key3") L4 (6): RETURN T0 

最初のケースでは、ファイル内にオペコードが1つしかないこと、つまり、完成した配列が返されることが明らかです。 2番目の場合、このファイルが実行されるたびに、要素ごとの構成が発生します。

したがって、実行時にさらなる変換を必要としない形式で構造を生成できます。 たとえば、オートロードのたびに記号「_」と「\」でクラス名を分解する代わりに、対応クラス「Class => Path」を事前生成できます。 この場合、変換関数は単一のハッシュテーブル呼び出しになります。 optimize-autoloaderオプションを有効にすると、Composerはこの種の最適化を行います 。

そのようなデータの無効化については、特に何もする必要はありません-通常のコード展開の場合と同じように、PHP自体が変更時にファイルを再コンパイルします。 忘れてはならない唯一の欠点：ファイルが非常に大きい場合、変更後の最初の要求は再コンパイルを引き起こし、目に見える時間がかかる可能性があります。

パフォーマンスには以下が含まれます/

静的配列の例とは異なり、クラスと関数の宣言を使用してファイルを添付するのはそれほど高速ではありません。 OPCacheが存在するにもかかわらず、PHPエンジンはそれらをプロセスメモリにコピーし、依存関係を再帰的に接続する必要があります。最終的には、ファイルごとに数百マイクロ秒またはミリ秒かかる場合があります。

Symfony 4.1で新しい空のプロジェクトを作成し、アクションの最初の行としてget_included_files（）を配置すると、310個のファイルが既に接続されていることがわかります。 実際のプロジェクトでは、この数はリクエストごとに数千に達する可能性があります。 次のことに注意する価値があります。

自動積載機能の欠如

Function Autoloading RFCがありますが、数年前から開発は行われていません。 したがって、Composerの依存関係がクラス外の関数を定義し、これらの関数にユーザーがアクセスできるようにする必要がある場合、これらの関数を含むファイルをオートローダーの各初期化に強制的に接続することによってこれを行います。

たとえば、composer.jsonから依存関係の1つを削除すると、多くの関数が宣言され、簡単に100行のコードに置き換えられるため、CPUの数パーセントを獲得しました。

オートローダーは、見かけよりも頻繁に呼び出されます。

アイデアを実証するために、クラスを使用してこのようなファイルを作成します。

 <?php class A extends B implements C {   use D;   const AC1 = \E::E1;   const AC2 = \F::F1;   private static $as3 = \G::G1;   private static $as4 = \H::H1;   private $a5 = \I::I1;   private $a6 = \J::J1;   public function __construct(\K $k = null) {}   public static function asf1(\L $l = null) :? LR { return null; }   public static function asf2(\M $m = null) :? MR { return null; }   public function af3(\N $n = null) :? NR { return null; }   public function af4(\P $p = null) :? PR { return null; } } 

オートローダーを登録します。

 spl_autoload_register(function ($name) {   echo "Including $name...\n";   include "$name.php"; }); 

そして、このクラスのいくつかのユースケースを作成します。

 include 'A.php' Including B... Including D... Including C... \A::AC1 Including A... Including B... Including D... Including C... Including E... new A() Including A... Including B... Including D... Including C... Including E... Including F... Including G... Including H... Including I... Including J... 

どういうわけかクラスを接続するが、そのインスタンスを作成しないと、親、インターフェイス、および特性が接続されることに気付くかもしれません。 これは、ファイルが解決されるときに接続されているすべてのファイルに対して再帰的に行われます。

インスタンスを作成すると、すべての定数とフィールドの解決がこれに追加され、これに必要なすべてのファイルが接続されます。これにより、新しく接続されたクラスの特性、親、およびインターフェイスの再帰的な接続が発生します。


インスタンス作成プロセスおよびその他の場合に関連するクラスを接続する

この問題に対する普遍的な解決策はありません。念頭に置いてクラス間の接続を監視する必要があります。1行で数百のファイルの接続をプルできます。

OPCache設定

PHPの作成者であるRasmus Lerdorfによって提案されたシンボリックリンクを変更してアトミックデプロイ方法を使用する場合、古いバージョンにシンボリックリンクを「貼り付ける」問題を解決するには、推奨されるようにopcache.revalidate_pathを含める必要があります。 .Ruグループ。

問題は、このオプションを使用すると（平均で1.5〜2倍）、各ファイルを含める時間が長くなることです。 合計すると、これはかなりの量のリソースを消費する可能性があります（この場合、このオプションを無効にすると7〜9％の利益が得られました）。

無効にするには、2つのことを行う必要があります。

• Webサーバーにシンボリックリンクを解決させます。
  
• シンボリックリンクを含むパスに沿ったPHPスクリプト内のファイルの接続を停止するか、readlink（）またはrealpath（）を介してそれらを強制します。
  

すべてのファイルがComposerオートローダーに接続されている場合、最初の項目が完了すると、2番目の項目が自動的に実行されます。omposerは__DIR__定数を使用します。これは正しく解決されます。

OPCacheには、柔軟性と引き換えにパフォーマンスを向上できるオプションがいくつかあります。 これについては、上記の記事で詳しく読むことができます。

これらすべての最適化にもかかわらず、インクルードはまだ無料ではありません。 これに対処するため、PHP 7.4はpreloadを追加する予定です。

APCuロック

ここではデータベースとサービスについては説明していませんが、さまざまな種類のロックがコード内で発生する可能性があり、スクリプトの実行時間が長くなります。

リクエストが増えるにつれて、ピーク時に応答が急激に遅くなることに気付きました。 理由を見つけた後、APCuは（Memcache、Redis、およびその他の外部ストレージと比較して）データを取得する最も速い方法ですが、同じキーを頻繁に上書きすることでゆっくりと動作することもあります。


1秒あたりのリクエスト数とランタイム：10月16日と17日にピーク

キャッシュとしてAPCuを使用する場合、キャッシュは通常、まれな書き込みと頻繁な読み取りを伴うため、この問題はあまり関係ありません。 ただし、一部のタスクとアルゴリズム（たとえば、 サーキットブレーカー （ PHPでの実装 ））も頻繁に記録を行うため、ロックが発生します。

この問題に対する普遍的な解決策はありませんが、サーキットブレーカーの場合、たとえば、PHPを搭載したマシンにインストールされた別のサービスに配置することで解決できます。

バッチ処理

インクルードを考慮しなくても、通常、クエリ実行時間のかなりの部分が初期化に費やされます：フレームワーク（たとえば、DIコンテナーの構築とそのすべての依存関係の初期化、ルーティング、すべてのリスナーの実行）、セッション、ユーザーなどのレイズさらに。

バックエンドが何かのための内部APIである場合、特定のクライアント上の一部のリクエストをバンドルして、単一のリクエストとして送信できます。 この場合、初期化は複数の要求に対して1回実行されます。

クライアントでこれが不可能な場合は、非同期で処理できるリクエストを見つけてください。それらは、何も初期化せず、単にキューに入れる単純なスクリプトによって受け入れられます。そして、すでにバッチで処理できます。

スマートリソース利用

Badooには、さまざまなニーズに合わせたさまざまなクラスターがあります。数百のサーバーがCPUにロードされ、ディスクがアイドル状態であるPHP-FPMを使用したクラスターに加えて、数百台のマシンの特定のデータベースクラスターがあります。

ここでの明らかな解決策は、2番目のクラスターでPHP-FPMを実行することでした。実際、PHPクラスターに追加で数百台のマシンを無料で追加しました。

(CPU, IO), . , , , , - , . , . , , .

おわりに

. PHP .

:

• ;
  
• ;
  
• - , : , ;
  
• : (, , );
  
• : ;
  
• , OPCache PHP, , , ;
  
• : (, , PHP 7.2 , );
  
• : , .
  

?

ご清聴ありがとうございました！