web-dev-qa-db-ja.com

PHPスクリプトの効率をベンチマークする方法

私のPHPスクリプトをベンチマークするための最良の方法は何かを知りたいです。 cronジョブ、Webページ、またはWebサービスのどちらでもかまいません。

マイクロタイムを使用できることは知っていますが、PHPスクリプトのリアルタイムを本当に提供してくれますか？

同じことを行うPHPのさまざまな関数をテストし、ベンチマークしたいです。たとえば、preg_match vs strposまたはdomdocument vs preg_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程度かかったことを意味します。

もっと良い方法はありますか？

phpperformancebenchmarkingmicrotime
117
eric

実際に実際のコードをベンチマークする場合は、 Xdebug や XHProf などのツールを使用します。

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

また、スクリプトで実行しているコードだけでなく、スクリプト/ページの処理方法を確認する必要もあります。どのWebサーバーを使用していますか？例として、nginx + PHP-FPMがmod_php + Apacheを真剣に実行するようにできます。これは、優れたCDNを使用して静的コンテンツを提供するために切り捨てられます。

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

  • ユーザーのブラウザでページがレンダリングされる速度が最優先事項ですか？
  • サーバーへの各リクエストを可能な限り迅速にスローバックし、最小のCPU消費で目標にしますか？

前者は、ブラウザーに送信されるすべてのリソースをgzip圧縮するなどの方法で支援できますが、そうすることで（状況によっては）後者の達成からさらに遠ざかることができます。

上記のすべてが、慎重に隔離された「ラボ」テストでは、本番環境で発生する変数や問題を反映していないこと、そして高レベルの目標が何であるかを特定し、そこに到達するために何ができるかを示す必要があることを示すのに役立つことを願っていますmicro/premature-optimisationに向かう前に 地獄へのルート 。

119
James Butler

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

次を使用できます。

71
Book Of Zeus

Xdebug 、より具体的には Xdebugのプロファイリング機能 をご覧ください。

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

Xdebugは設定するのが少し難しい場合があるので、参照用に私のphp.iniの関連セクションを以下に示します。

[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ファイルのスクリーンショットです：

enter image description here

これにより、PHPスクリプトの効率性に関する十分な詳細が提供されます。最も時間がかかるものをターゲットにしたい。たとえば、1つの関数を半分の時間で最適化できますが、ページの読み込み中に数百回ではなくても数十回と呼ばれる関数を最適化する方がより効果的です。

好奇心が強い場合、これは私自身が使用するために作成したCMSの古いバージョンです。

26
Alec Gorge

試す 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
)
16
fotuzlab

xhprof を調べます。 CLIで実行するか、別のsapi（fpm、fcgi、またはApacheモジュールなど）で実行するかは関係ありません。

Xhprofの最大の利点は、実稼働環境で実行するのに十分であることです。 xdebugでうまく機能しないもの（前回チェックしました）。 xdebugはパフォーマンスに影響を与え、xhprof（何も存在しないとは思わない）の方がはるかに優れています。

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

timeを取得するという点では、実際にはベンチマークではありませんが、それでも同様です。実稼働トラフィックを非常に簡単に分析し、収集されたコールグラフのphp関数レベルにドリルダウンするだけです。

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

xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

止まる：

$xhprof_data = xhprof_disable();

次に、データをファイルまたはデータベースに保存します-あなたのボートに浮かぶものは何でも、通常のランタイムを中断しません。これを非同期的にS3にプッシュして、データを集中化します（すべてのサーバーからのすべての実行を確認できるようにするため）。

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

HTH！

7
Till

forループに入れて、各処理を1,000,000回実行し、より現実的な数を取得します。そして、実際にベンチマークしたいコードの直前でタイマーを開始し、直後に終了時間を記録します（つまり、session_start()の前にタイマーを開始しないでください。

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

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

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

3
Alasdair

良いスタートは、xdebugsプロファイラーを使用することです http://xdebug.org/docs/profiler

設定して使用するのが最も簡単な方法ではないかもしれませんが、一度データを取得すると、膨大な量のデータと使いやすさはかけがえのないものになります。

1
goat

コーディング自体がアプリのパフォーマンスを妨げないようにするために、PHPコードに注目し、この link とクロスチェックすることも良いことです。 。

0
Ritesh Aryal

エリック、

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

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

0
TerryE

私の答えは以下から得られます： https://stackoverflow.com/a/28868536/306656

<?php
function yourFunction(){
  echo 'Code Im benchmarking';
}

$time_start = microtime(true);

$times=0;               // This couldn't be tough
while($times<1000)
{
   yourFunction();
   $times++;
}


$time_end = microtime(true);
$time = $time_end - $time_start;

echo "Did yourFunction in $time seconds\n";
?>

YourFunctionのコードをベンチマークに変更するだけです。

0
Jeff Luyet