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

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

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

PHPで同じことを行うさまざまな関数をテストしてベンチマークしたい。たとえば、preg_matchvs strposまたはdomdocumentvs 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ほどかかりました。

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

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

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

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

次に検討すべきことは、最適化しようとしているものですか？

• ユーザーのブラウザでページがレンダリングされる速度が最優先事項ですか？
• 最小のCPU消費で可能な限り迅速にサーバーへの各要求を返すことは目標ですか？

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

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

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

以下を使用できます。

• jmeter
• ApacheBenchツール（例を参照）
• dbench
• http_load
• カールローダー
• httperf
• 包囲
• ベジータ
• 使用するコードも良いですが、より大きなループ（1,000,000など）

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

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

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

そして.out、これがWinCacheGrind内のファイルのスクリーンショットです。

これにより、PHPスクリプトがいかに効率的であるかについて十分な詳細情報が提供されます。最も時間がかかるものをターゲットにしたいとします。たとえば、1つの関数を半分の時間で最適化できますが、ページのロード中に数百回とは言わないまでも数十回と呼ばれる関数を最適化するほうがよいでしょう。

興味があれば、これは私が自分用に書いたCMSの古いバージョンです。

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
)

私はに見てね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！

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

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

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

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

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

設定して使用するのが最も簡単なことではないかもしれませんが、一度取得すれば、膨大な量のデータと表示の容易さはかけがえのないものです。

エリック、

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

ここでの主な問題は、ロード時間に対するユーザーの認識です。つまり、リンクをクリックしてから完全にレンダリングされたページが表示されるまでにどれくらい待つ必要があるかです。見ていGoogleのページスピードあなたはFfは、クロムの拡張、および優れたページのパフォーマンスを得るためにどのように深さを議論のPageSpeedのドキュメントとして使用することができます。これらのガイドラインに従い、ページのスコアが90/100よりも高くなるようにしてください。（Googleホームページは私のブログと同様に99/100を記録します）。これは、ユーザーが感じるパフォーマンスを向上させる最良の方法です。

また、コーディング自体がアプリのパフォーマンスに影響を与えていないことを確認するために、PHPコードに注意を払い、このリンクを確認してください。