146

PHP スクリプトをベンチマークする最良の方法を知りたいです。cron ジョブ、Web ページ、Web サービスのいずれであっても問題ありません。

マイクロタイムを使用できることはわかっていますが、実際に PHP スクリプトのリアルタイム時間を取得できますか?

同じことを行うPHPのさまざまな機能をテストしてベンチマークしたいと考えています。たとえば、preg_matchvsstrposまたはdomdocumentvspreg_matchまたは preg_replace vs str_replace`

ウェブページの例:

<?php
// login.php

$start_time = microtime(TRUE);

session_start(); 
// do all my logic etc...

$end_time = microtime(TRUE);

echo $end_time - $start_time;

これは次のように出力されます: 0.0146126717 (常に変化します - しかし、それは私が得た最後のものです)。これは、PHP スクリプトの実行に 0.015 程度かかったということです。

より良い方法はありますか？

4

7 に答える 7

132

実世界のコードを実際にベンチマークしたい場合は、XdebugやXHProfなどのツールを使用してください。

Xdebug は、開発/ステージングで作業している場合に最適です。XHProf は、本番用の優れたツールであり、そこで実行しても安全です (手順を読む限り)。1 つのページの読み込みの結果は、サーバーが他の何百万ものことを実行するためにハンマーを打たれ、リソースが不足している間にコードがどのように実行されるかを確認するほど重要ではありません。これにより、別の疑問が生じます。CPU のボトルネックになっていませんか? 羊？I/O?

また、スクリプトで実行しているコードだけでなく、スクリプト/ページがどのように提供されているかにも目を向ける必要があります。どのWebサーバーを使用していますか? 例として、nginx + PHP-FPM で mod_php + Apache を大幅に上回るパフォーマンスを実現できます。これは、優れた CDN を使用して静的コンテンツを提供することで打ち負かされます。

次に考慮すべきことは、何を最適化しようとしているのかです。

  • ユーザーのブラウザでページが表示される速度が最優先ですか?
  • サーバーへの各リクエストを可能な限り迅速にスローバックして、CPU 消費を最小限に抑えることが目標ですか?

前者は、ブラウザに送信されたすべてのリソースを gzip するなどの方法で解決できますが、そうすると (場合によっては) 後者の達成から遠ざかる可能性があります。

上記のすべてが、慎重に分離された「ラボ」テストが本番環境で遭遇する変数や問題を反映していないこと、および高レベルの目標が何であるかを特定し、そこに到達するために何ができるかを特定する必要があることを示すのに役立つことを願っています.地獄へのマイクロ/時期尚早の最適化ルートに向かう前に.

于 2011-12-04T02:16:48.933 に答える
78

完全なスクリプトがサーバー上で実行される速度をベンチマークするために、使用できるツールはたくさんあります。最初に、スクリプト (たとえば、preg_match と strpos) がテストを認定するために同じ結果を出力する必要があることを確認します。

以下を使用できます。

于 2011-12-04T02:35:32.590 に答える
31

Xdebug、より具体的には、Xdebug のプロファイリング機能を確認する必要があります。

基本的に、プロファイラーを有効にすると、Web ページをロードするたびに、 WinCacheGrindまたはKCacheGrindで読み取ることができる cachegrind ファイルが作成されます。

Xdebug は構成が少し難しい場合があるためphp.ini、参照用に my の関連セクションを以下に示します。

[XDebug]
zend_extension = h:\xampp\php\ext\php_xdebug-2.1.1-5.3-vc6.dll
xdebug.remote_enable=true
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=h:\xampp\cachegrind
xdebug.profiler_output_name=callgrind.%t_%R.out

WinCacheGrind.out内のファイルのスクリーンショットは次のとおりです。

ここに画像の説明を入力

これにより、PHP スクリプトがどれほど効率的であるかについて十分な詳細が得られるはずです。最も時間がかかるものをターゲットにする必要があります。たとえば、1 つの関数を最適化して時間が半分になるようにすることもできますが、ページの読み込み中に数百回とは言わないまでも、数十回呼び出される関数を最適化する方が効果的です。

興味がある方のために説明すると、これは私が自分用に書いた古いバージョンの CMS です。

于 2011-12-04T02:17:17.717 に答える
16

https://github.com/fotuzlab/appgati を試してください

コード内のステップを定義し、2 つのステップ間の時間、メモリ使用量、サーバー負荷などを報告できます。

何かのようなもの：

    $appgati->Step('1');

    // Do some code ...

    $appgati->Step('2');

    $report = $appgati->Report('1', '2');
    print_r($report);

サンプル出力配列:

Array
(
    [Clock time in seconds] => 1.9502429962158
    [Time taken in User Mode in seconds] => 0.632039
    [Time taken in System Mode in seconds] => 0.024001
    [Total time taken in Kernel in seconds] => 0.65604
    [Memory limit in MB] => 128
    [Memory usage in MB] => 18.237907409668
    [Peak memory usage in MB] => 19.579357147217
    [Average server load in last minute] => 0.47
    [Maximum resident shared size in KB] => 44900
    [Integral shared memory size] => 0
    [Integral unshared data size] => 0
    [Integral unshared stack size] => 
    [Number of page reclaims] => 12102
    [Number of page faults] => 6
    [Number of block input operations] => 192
    [Number of block output operations] => 
    [Number of messages sent] => 0
    [Number of messages received] => 0
    [Number of signals received] => 0
    [Number of voluntary context switches] => 606
    [Number of involuntary context switches] => 99
)
于 2013-06-23T08:21:11.047 に答える
7

xhprofを調べます。cliで実行するか、別のsapi（fpmやfcgi、さらにはApacheモジュールなど）を介して実行するかは関係ありません。

xhprofの最も優れている点は、本番環境で実行するのに十分な適合性があることです。xdebugではうまく機能しないもの（前回チェックしたとき）。xdebugはパフォーマンスに影響を与え、xhprof（何もないとは言えません）の管理が大幅に向上します。

xhprofを頻繁に使用して、実際のトラフィックを含むサンプルを収集し、そこからコードを分析します。

それはあなたに時間とそのすべてを与えるという点で実際にはベンチマークではありませんが、それもそうします。これにより、本番トラフィックの分析が非常に簡単になり、収集されたコールグラフのphp関数レベルにドリルダウンできます。

拡張機能がコンパイルおよびロードされたら、次のコードでプロファイリングを開始します。

xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

止まる：

$xhprof_data = xhprof_disable();

次に、データをファイルまたはデータベースに保存します。これは、ボートを浮かせて、通常の実行時間を中断しないものです。これを非同期的にS3にプッシュして、データを一元化します（すべてのサーバーからのすべての実行を表示できるようにするため）。

githubのコードには、サーバーにダンプするxhprof_htmlフォルダーが含まれており、最小限の構成で、収集されたデータを視覚化してドリルダウンを開始できます。

HTH！

于 2011-12-04T02:34:29.677 に答える
3

より現実的な数値を得るために、forループに入れて各ことを 1,000,000 回実行します。そして、実際にベンチマークしたいコードの直前にのみタイマーを開始し、直後に終了時刻を記録します (つまり、session_start().

また、タイミングを計っている関数を除いて、ベンチマークする各関数のコードが同一であることを確認してください。

スクリプトの実行方法 (cronjob、コマンドラインからの php、Apache など) は、異なる関数の速度の相対的な違いを計っているだけなので、違いはありません。したがって、この比率は変わらないはずです。

ベンチマークを実行しているコンピューターで他の多くの処理が行われている場合、ベンチマークの実行中に別のアプリケーションから CPU またはメモリの使用量が急激に増加すると、ベンチマークの結果に影響を与える可能性があります。しかし、コンピュータに余裕のあるリソースがたくさんある限り、これは問題にはならないと思います。

于 2011-11-28T03:57:47.877 に答える
0

エリック、

あなたは自分自身に間違った質問をしています。スクリプトが ~15 ミリ秒で実行されている場合、その時間はほとんど関係ありません。共有サービスで実行している場合、PHP イメージのアクティブ化には約 100 ミリ秒かかり、サーバーに完全にキャッシュされている場合は約 30 ～ 50 ミリ秒、バックエンド NAS ファームからロードされている場合はおそらく 1 秒以上のスクリプト ファイルを読み取ります。ページ ファニチャーの読み込みにおけるネットワークの遅延により、数秒が追加される可能性があります。

ここでの主な問題は、読み込み時間に対するユーザーの認識です。つまり、リンクをクリックしてから完全にレンダリングされたページを取得するまでにどれくらい待たなければならないかということです。Ff または chrome 拡張機能として使用できるGoogle Page Speedと、優れたページ パフォーマンスを得る方法について詳しく説明しているPagespeedドキュメントをご覧ください。これらのガイドラインに従って、ページのスコアが 90/100 を超えるようにしてください。(私のブログと同様に、Google ホームページのスコアは 99/100 です)。これは、ユーザーが認識する優れたパフォーマンスを得る最良の方法です。

于 2012-01-24T18:30:46.020 に答える