PHP のパフォーマンスを詳しく見る

1. 由来

PHP に関して、多くの人の直観的な印象として、PHP は豊富なライブラリ クラスを備えた柔軟なスクリプト言語であり、使いやすく、安全で、WEB 開発に非常に適していますが、パフォーマンスは低いです。 PHP のパフォーマンスは本当に誰もが感じているほど悪いのでしょうか? この記事ではそのようなトピックに焦点を当てます。ソース コード、アプリケーション シナリオ、ベンチマーク パフォーマンス、比較分析などの側面から PHP パフォーマンスの問題を詳細に分析し、実際のデータを通じて語ります。

2.原理からPHPのパフォーマンスを分析する

PHP のパフォーマンスを原理から、主にメモリ管理、変数、関数、動作メカニズムの側面から分析します。

2.1 メモリ管理

Nginx のメモリ管理方法と同様に、PHP も内部的にメモリ プールに基づいており、メモリ プールのライフサイクル概念を導入しています。メモリ プールに関しては、PHP は PHP スクリプトと拡張機能のメモリ関連のすべての操作を管理します。大規模メモリと小規模メモリの管理には、さまざまな実装方法と最適化が使用されます。詳細については、https://wiki.php.net/internals/zend_mm のドキュメントを参照してください。メモリの割り当てとリサイクルのライフサイクル中に、PHP は初期化アプリケーション + 動的拡張 + メモリ識別リサイクル メカニズムを使用し、各リクエストの後にメモリ プールを直接再マスクします。

2.2 変数

ご存知のとおり、PHP は弱い変数型の言語であるため、PHP 内ではすべての PHP 変数が Zval 型に対応し、これは具体的に次のように定義されます。

図 1 PHP 変数

変数に関しては、PHP は参照カウントやライター メカニズムのコピーなど、多くの最適化作業を行ってきました。これにより、メモリ使用量が確実に最適化され、メモリ コピーの数が削減されます (http://blog.xiuwz.com/2011/11/09 /php-using-internal-zval/ を参照してください)。配列に関しては、PHP は効率的なハッシュテーブルを内部で使用して実装します。

2.3 関数

PHP 内では、すべての PHP 関数が内部関数ポインターに変換されます。たとえば、展開関数

ZEND_FUNCTION ( my_function );// 関数 my_function() と同様{}

内部展開後は関数となります

void zif_my_function (INTERNAL_FUNCTION_PARAMETERS);

void zif_my_function(

int ht、

zval * return_value,

zval * this_ptr,

int return_value_used,

zend_executor_globals * executor_globals

);

この観点から見ると、PHP 関数も内部的には関数ポインタに対応します。

2.4 動作メカニズム

PHP のパフォーマンスについて話すとき、多くの人は「C/C++ はコンパイルされ、JAVA はセミコンパイルされ、PHP はインタープリタされます」と言うでしょう。つまり、PHP は最初に動的に解析されてからコードが実行されるため、この観点から見ると、PHP のパフォーマンスは非常に悪いはずです。

実際、PHP スクリプトの実行による出力は、動的解析とコード実行のプロセスです。具体的には、PHP スクリプトの実行メカニズムは次のようになります。

図2 PHPの動作仕組み

PHP の実行フェーズも 3 つのフェーズに分かれています:

解析します。構文解析段階。

コンパイル。オペコードの中間コードをコンパイルして出力します。

実行する。実行して、出力のために動的に実行します。

したがって、PHP 内にもコンパイル プロセスがあります。そしてこれに基づいて、apc、eacc、xcache などの多数のオペコード キャッシュ ツールが作成されています。これらのオペコード キャッシュは基本的に運用環境では標準です。オペコード キャッシュに基づいて、「PHP スクリプトを 1 回コンパイルして複数回実行する」効果を実現できます。この点から、PHP は JAVA のセミコンパイルされたメカニズムに非常に似ています。

したがって、動作メカニズムの観点から見ると、PHP の動作モードは JAVA の動作モードと非常に似ています。両方の中間コードが最初に生成され、その後、異なる仮想マシン上で実行されます。

2.5 動的操作

上記の分析から判断すると、PHP はメモリ管理、変数、関数、操作メカニズムなどで多くの作業を行ってきました。したがって、原理的な観点からは、PHP にパフォーマンスの問題はなく、そのパフォーマンスは少なくとも同等であるはずです。 Java に比較的近いので良いです。

ここで、PHP の動的言語の特性によって引き起こされるパフォーマンスの問題について説明する必要があります。PHP は動的ランタイムであるため、すべての変数、関数、オブジェクト呼び出し、スコープの実装などは実行フェーズで決定されます。これは、PHP のパフォーマンスにおいて変更が難しいいくつかのことを根本的に決定します。C/C++ の静的コンパイル段階で決定できる変数と関数は、PHP の動的実行で決定する必要があり、これにより、PHP 中間コードを直接実行できないことも決定されます。 Zend Engine で実行する必要があります。

PHP 変数の具体的な実装に関しては、もう 1 つ、ハッシュテーブルについて話さなければなりません。 Hashtable は PHP の魂の 1 つと言え、変数シンボル スタック、関数シンボル スタックなど、すべて Hashtable をベースにした PHP 内で広く使用されています。

PHP 変数を例として、PHP の動的操作特性を説明します。たとえば、次のコードです。

$var = “こんにちは、blog.xiuwz.com”;

?>

このコードの実行結果は、項目

を変数シンボル スタック (ハッシュテーブル) に追加します。

変数を使用する場合は、変数スタックに移動して検索します (つまり、変数呼び出しによってハッシュ検索プロセスが作成されます)。

同様に、関数呼び出しの場合、基本的に関数シンボル スタック (ハッシュテーブル) が存在します。

実際、動的操作の変数検索特性の一部は、PHP の操作メカニズムにも見られます。解釈とコンパイル後の PHP コードの流れは次のとおりです:

図3 PHPの実行例

上の図からわかるように、PHP コードがコンパイルされると、クラス シンボル テーブル、関数シンボル テーブル、および OPCODE が生成されます。実際の実行中、zend エンジンはオペコードに従って対応するシンボルテーブルを検索して処理します。

ある程度、この問題の解決策を見つけるのは困難です。これは、PHP 言語の動的な特性によって決定されるためです。しかし、解決策を探している人も国内外にたくさんいます。これにより、PHP を根本的かつ完全に最適化できるからです。代表的な例は Facebook のヒップホップ (https://github.com/facebook/hiphop-php) です。

2.6 結論

上記の分析から、基本的なメモリ管理、変数、関数、および動作メカニズムの点では、PHP 自体には明らかなパフォーマンスの違いはありませんが、PHP の動的な動作特性により、PHP と他のコンパイル言語との比較が決定されます。 、すべての変数検索、関数実行などでは、より多くの CPU オーバーヘッドと、ハッシュ検索のための追加のメモリ オーバーヘッドが発生します。このオーバーヘッドの具体的な量については、その後のベンチマーク パフォーマンスと比較分析によって取得できます。

したがって、大量の計算タスク、大量のデータ操作、メモリ要件が厳しいアプリケーション シナリオなど、PHP が適さないいくつかのシナリオも大まかに把握できます。これらの関数を実装する場合は、拡張機能を使用して実装し、PHP 呼び出しのフック関数を提供することもお勧めします。これにより、内部で計算される変数、関数などのオーバーヘッドを削減できます。

3. ベースラインパフォーマンス

PHP ベンチマークのパフォーマンスについては、現在標準データが不足しています。ほとんどの学生は、800QPS が PHP の限界であると考えています。さらに、フレームワークのパフォーマンスやフレームワークがパフォーマンスに与える影響に関する信頼できる数字はほとんどありません。

この章の目的は、ベンチマークの参照パフォーマンス指標を提供し、データを通じて誰もが直感的に理解できるようにすることです。

具体的なベンチマーク パフォーマンスには次の側面が含まれます:

1. 裸の PHP パフォーマンス。基本機能を完備。

2. 裸のフレームワークのパフォーマンス。最も単純なルート配布のみを実行し、コア機能のみを通過させます。

3. 標準モジュールのベースラインパフォーマンス。標準モジュールのいわゆるベンチマーク パフォーマンスとは、完全なサービス モジュール機能のベンチマーク パフォーマンスを指します。

3.1 環境の説明

テスト環境:

うなめ -a

Linux db-forum-test17.db01.baidu.com 2.6.9_5-7-0-0 #1 SMP Wed Aug 12 17:35:51 CST 2009 x86_64 x86_64 x86_64 GNU/Linux

Red Hat Enterprise Linux AS リリース 4 (ナハント アップデート 3)

8 Intel(R) Xeon(R) CPU E5520 @ 2.27GHz

ソフトウェア関連:

Nginx:

nginx バージョン: gcc 3.4.5 20051201 (Red Hat 3.4.5-2) によってビルドされた nginx/0.8.54

Php5: (php-fpm を使用)

PHP 5.2.8 (cli) (ビルド: 2011 年 3 月 6 日 17:16:18)

Copyright (c) 1997-2008 PHP グループ

Zend Engine v2.2.0、著作権 (c) 1998-2008 Zend Technologies

eAccelerator v0.9.5.3 を使用、著作権 (c) 2004-2006 eAccelerator、eAccelerator 作成

ビンゴ2：

PHP フレームワーク。

その他の指示:

ターゲットマシンの展開方法:

スクリプト。

テスト ストレス マシンとターゲット マシンは独立してデプロイされます。

3.2 裸の PHP パフォーマンス

最も単純な PHP スクリプト。

require_once ‘./actions/indexAction.php’;

$objAction = 新しいindexAction();

$objAction->init();

$objAction->execute();

?>

Acitons/indexAction.php のコードは次のとおりです

クラスインデックスアクション

{

パブリック関数execute()

{

echo ‘hello, world!’;

}

}

?>

圧力ツールテストの結果は次のとおりです:

3.3 裸の PHP フレームワークのパフォーマンス

3.2 との比較のために、bingo2 フレームワークに基づいて同様の機能が実装されています。コードは次のとおりです

require_once ‘Bingo/Controller/Front.php’;

$objFrontController = Bingo_Controller_Front::getInstance(array(

「actionDir」 => 「./actions」,

));

$objFrontController->dispatch();

ストレステストの結果は次のとおりです:

テスト結果から、フレームワークはある程度のコストを消費しますが、全体的なパフォーマンスへの影響は非常に小さいことがわかります。

3.4 標準 PHP モジュールのベースライン パフォーマンス

いわゆる標準 PHP モジュールは、PHP モジュールに必要な特定の基本機能を指します。

ルート配布。

自動読み込み。

LOGの初期化と通知ログの印刷。すべての UI リクエストには標準ログがあります。

エラー処理。

時間修正。

各ステージの時間のかかるオーバーヘッドを自動的に計算します。

コード認識とコード変換。

標準設定ファイルの解析と呼び出し

bingo2 の自動コード生成ツールを使用して、標準テスト PHP モジュール test を生成します。

テスト結果は次のとおりです:

3.5 結論

テストデータの結論から判断すると、PHP 自体のパフォーマンスはまだ許容範囲内です。ベースライン パフォーマンスは、数千または QPS の W に達する場合もあります。ほとんどの PHP モジュールのパフォーマンスが低い理由については、実際のところ、現時点ではシステムのボトルネックを特定する必要があります。「OK、PHP は良くない」と言って、C に切り替えましょう。 (次の章では、比較のためにいくつかの例を使用します。C を使用して処理することに特に利点はないかもしれません)

ベンチマーク データを通じて、次の具体的な結論を導き出すことができます:

1. PHP 自体のパフォーマンスは非常に優れています。単純な関数で 5000QPS に達することができ、制限は W を超えることもあります。

2. PHP フレームワーク自体がパフォーマンスに与える影響は非常に限定的です。特に、特定のビジネス ロジックとデータの相互作用がある場合、それはほとんど無視できます。

3. 標準 PHP モジュールのベンチマーク パフォーマンスは 2000QPS (80 CPU アイドル時) に達します。

4. 比較分析

多くの場合、PHP モジュールのパフォーマンスが良くないことがわかったとき、人々は「よし、C で書き直そう」と言うだけです。社内では、ビジネス ロジック モジュールを作成するために C/C++ が使用されているのがここ数年、ほとんどすべて C で作成されています。当時、誰もが書いたことは本当に痛ましいものでした。デバッグは難しい、アジリティは議論されるべきではありません。