PHP パフォーマンスのディスカッションとテスト_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 環境の説明

テスト環境:

Uname -aPnux 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/Pnux

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

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

软件相关：

Nginx：nginx バージョン: nginx/0.8.54 build by gcc 3.4.5 20051201 (Red Hat 3.4.5-2)

Php5：（採用php-fpm）

PHP 5.2.8 (cP) (ビルド: Mar 6 2011 17:16:18)

Copyright (c) 1997-2008 The PHP Group

Zend Engine v2.2.0、Copyright (c) 1998-2008 Zend Technologies

eAccelerator v0.9.5.3 を使用、Copyright (c) 2004-2006 eAccelerator、eAccelerator 製

ビンゴ2：

PHPフレームワーク。

その他の指示:

ターゲットマシンのデプロイ方法: nginx->php-fpm->php スクリプト。

テストストレスマシンとターゲットマシンは独立して展開されます。

3.2 裸の PHP パフォーマンス

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

require_once ‘./actions/indexAction.php’;

$objAction = 新しいindexAction();

$objAction->init();

$objAction->execute();

?>

Acitons/indexAction.phpのコードは以下の通りです

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

{

pubPc関数execute()

{

「こんにちは、世界!」をエコーし​​ます;

}

}

?>

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

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 アイドル時) に達します。

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

http://www.bkjia.com/PHPjc/371766.html

www.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/371766.html技術記事 1. 由来 PHP について、多くの人の直観的な印象として、PHP は豊富なライブラリ クラスを備えた柔軟なスクリプト言語であり、使いやすく、安全で、WEB 開発に非常に適していますが、パフォーマンスは低いです。 PHPのパフォーマンスですか...