PHP開発における周辺リソースのパフォーマンス最適化の分析

まず第一に、この記事では、バックエンド周辺リソースとは、PHP の実行中に言語自体とは関係のないネットワークおよび IO 操作、ストレージ サービス、ミドルウェア エージェント、キャッシュ、データベース アクセスなどを指します。では、まず IO 操作とミドルウェア サービスを分析します。

なぜ周辺リソースのパフォーマンス分析は上記の 3 つの分析に基づく必要があるのですか?国内のプロフェッショナルなパフォーマンス監視ツールである OneAPM の PHP Web アプリケーション バックエンドから取得した次の概要図を見ると、データベースで費やされる時間が PHP 全体の 60% 以上を占めていることがわかります。この図では、Memcached キャッシュ サービスが占める応答時間はほとんど見えません。

1. IO 操作

PHP 言語自体にはパフォーマンスの違いがありますが、PHP のパフォーマンスのミクロ分析からも、単一の操作のみが実行される場合、その差は実際には非常に小さいことがわかります (前の実験では 10 万)。 PHP 言語自体はメモリ上で動作し、メモリ アクセスには約 50ns かかるため、上記の操作には数百ミリ秒の差しかありません。 IO 操作はディスク アクセスであり、ディスク アクセスには 5 ミリ秒以上かかります。この桁だけでも 10 万倍の差があります。実際、実験によると数百倍の差もあります (シーケンシャル アクセスとランダム アクセスの間には大きな差があります。実際には両方が実行されます)。同時に、ディスク キャッシュなどもあります)。

つまり、言語自体と比較して、IO がボトルネックになる可能性が高くなります。まず、IO 操作によって生じるパフォーマンスの違いを見てみましょう。

PHP スクリプトは、PHP コマンド モードで実行されます。通常、所要時間は次のとおりです。

次のコマンドを使用してディスク キャッシュをクリアした後:

echo 3 | sudo tee /proc/sys/vm/drop_caches

コードはまったく同じですが、実行時間は通常の 6 倍です。もちろん、この遅い時間はプログラム自体の IO 操作だけが原因ではありません。さらに大きな遅い要因は、CGI モードでは、PHP スクリプトを実行するたびにすべてのモジュールをロードする必要があることです。このロードには、多数の IO 操作。

まったく同じ機能を持つ 2 つのページをもう 1 つ試してみましょう。1 つは MVC メソッドを採用し、ヘッダーとテールを独立したテンプレートに分割し (テンプレート エンジンを使用せず)、中間ロジックも独立した Model クラスを使用します。ハンドル。もう 1 つは、マクロ定義とデータベース操作の 2 つのファイルのみが必要です。

コマンド ab -c 40 -n 1000 http://xxxxx/0929/zuche/carlist.php を使用してストレス テストを実行します。これらの 2 つのページが安定したら、ストレス テストの結果データを実行します。

このページでは、MVC バージョンの方が 6 ～ 8 ミリ秒ほど時間がかかります。ファイルのインクルードがいくつか追加されるだけですが、ファイルのアップロード、検出、変換などのファイル操作自体がより複雑な場合、遅延は明らかに 1 桁以上増加します。実際の運用環境では、この例の require のように、ディスク キャッシュの存在などにより、遅延の影響は大幅に軽減されているため、ファイル操作によって必然的に大きな遅延が発生するというわけではありません。

2. ミドルウェアプロキシ

ミドルウェアを正式に使用する前に、データベースを使用する場合と使用しない場合の違いを比較してみましょう。上記の同じ例では、構造のために、データベースから取得したデータ結果セットを直接結果の配列設定に変換します。明確にするために、このバージョンの MVC を使用してください。同時に、前のラウンドのテスト結果をより明確に比較し、言語自体の遅い要因を取り除くために、このラウンドの実験では PHP7 を使用しました。その結果は驚くべきものでした。 下の図はデータベース接続とデータ読み込みを行ったバージョンです。PHP 拡張機能は mysqli を使用します。

このページにはデータベース操作が 1 つしかなく、ページ構造が比較的単純であるため、PHP7 では速度自体が 37 ～ 40 ミリ秒以上高速化されました。しかし今は14ミリ秒です。

それでも、データベースを読み取っていないときは 4 ミリ秒のギャップがあり、その数は大きくありませんが、合計応答時間がわずか 14 ミリ秒のアプリケーションでは、この 4 ミリ秒はすでに重要であり、これは単なるデータベース クエリです。手術。

データベースミドルウェアの層が追加されたときに効率がどのように変化するかを見てみましょう。現在、作者が使用しているミドルウェアがPHP7に対応していないため、古いバージョンのPHPをベースに比較を行っています。同じサーバー負荷の下では、ミドルウェアを使用したバージョンは 2 倍以上遅くなります。

この例から、最初は PHP がデータベースに直接接続してデータ操作を取得し、ミドルウェアを追加した後、最初にミドルウェアに変更され、次にミドルウェアに変更され、次にデータベースに変更されて、戻り値が返されたことがわかります。これにより、速度が大幅に向上します (ここでは、ミドルウェア自体がリソースを占有する要因が除去されています。元の直接接続バージョンでは、約 37 ～ 40 ミリ秒でした)。

ここで誤解しないでください。ミドルウェアの使用が遅くなる例は、分散環境ではミドルウェアの使用が非常に必要であることを示しているわけではありません。むしろ、プログラムの外部リソースは、特に外部リソースの接続速度やデータ取得自体の速度が望ましい結果を達成できない場合、パフォーマンスに影響を与える重要な要素となることがよくあります。

IO 操作とミドルウェア サービスの分析はここまでです。次の部分では、アプリケーション全体のパフォーマンスに対するデータベースの影響を分析します。