管理者の手によるxdebug

この記事では、Webサーバーのシステム管理者がxdebugを使用する可能性について説明します。 これはプログラマの仕事であるため、管理者はコードの診断とデバッグに関与すべきではないように思われるかもしれません。 そうです。 しかし、問題が発生した場合、プログラマーにコードが最適ではなく（これが正しい場合）、プログラマーが常に「私たちは大丈夫-サーバーを修復します」と言う場合、やり直す必要があると確信させるにはどうすればよいですか？ これは、議論するのが望ましくないプログラマーであると想像してください。 たとえば、私たちの非常に親しみやすくinしているクライアントです。

Webサーバーを管理する際、エンジニアはサイトの一般ユーザーが「スロー」または「スローダウン」と呼ぶ問題に遭遇することがよくあります。 もちろん、これは非常に重要な問題であり、サイト所有者に深刻な財政的影響を与える可能性があります。 ユーザーやWebサイトの所有者が通常Webサーバー管理者に連絡するのは、この「スローワーク」という言葉遣いであり、この言葉遣いはすべてを診断するのに十分です。

興味深いことに、このような問題の原因はほとんどどこにでも隠されています。 また、いくつかの理由があり、問題自体を再現するのが難しい場合があります。 ユーザーが最終的に下位レベルで「ブレーキ」として分類するものは次のとおりです。

• サイトへのネットワークアクセスチャネルの遅​​延
• サーバーのハードウェアの問題
• サーバーリソースが不足しています
• 準最適なオペレーティングシステム
• 最適ではないソフトウェア
• サードパーティのリソースへのアクセスに関する問題。アクセスは同期的に実装されます
• 最適でないサイトコード

管理者のタスクは、これらの問題を特定し、可能であれば排除することです。 もちろん、彼らが彼の責任範囲内にいる場合。 そして最後の、そしておそらく最後から2番目のポイントは、彼の責任範囲には含まれていません。 しかし、問題がこれらの点に正確にあることを示すことも必要です。

後者のケースについては、記事で説明します。 実践によると、このケースはサイトの遅い動作に関連するすべての問題の約90％を占めています。 最適でないコード、不十分なSQLクエリ、不適切なロックの使用-これらすべてがサイトの速度を低下させる可能性があります。 そして、ある時点まで強力なハードウェアが不良コードをダイジェストできた場合、ある時点「x」が出現すると、単に負荷に対処しなくなります。 容量をさらに増やすことは可能ですが、第一に、いつかは使い果たされ、第二に、これは不必要な設備コストです。 したがって、まず問題の解決策は、サイトコードの分析から始める必要があります。

新しいハードウェアの取得は、大量のコードを解析および編集するよりも経済的に利益がある場合があることに注意してください。

奇妙なことに、管理者のメインタスク-サーバー管理。 彼は開発者ではなく、たとえうまく機能しなくても、コードに触れる道徳的権利はありません。 したがって、このコードの最も詳細な診断を行い、Webサイトの動作が遅くなるボトルネックを特定するには、コードの編集を必要としないツールを使用する必要があります。

はい、私は完全に忘れました、それはPHPで開発することです！ ほとんどのWebプログラマーはそれを使用し、愛しています。 「愛」を犠牲にして、質問はかなり物議を醸しています。

Xdebug

Xdebugは、 PHP開発者の1人によって記述されたPHP拡張機能であり、 PHPコードのデバッグ情報を収集および分析するように設計されています。 これはオープンソースプロジェクトであることに注意することが重要です。

システム管理者のプリズムを通してxdebugを検討します。これは、サイトコードの編集を必要とせず、サーバーの速度を低下させない機能のみに影響します。

明らかに、プロファイリングまたはトレースは、コード実行中に追加の遅延をもたらします。 したがって、診断はサイトのパフォーマンスに影響を与えません。

Xdebugのインストール

Centos / RHEL / Fedoraを使用する場合、xdebugをインストールする最も簡単な方法はEPELリポジトリからインストールすることです：

$ yum install php-pecl-xdebug

peclを使用したインストール：

$ pecl install xdebug

最初にhttp://xdebug.org/download.phpからダウンロードして、ソースコードからxdebugをインストールすることもできます。

$ tar xvzf xdebug-2.2.1.tgz
$ cd xdebug-2.2.1
$ phpize
$ ./configure --enable-xdebug
$ make && make install

Xdebugセットアップ

基本的なセットアップは、新しくインストールした拡張機能をphp.iniファイルに単純に接続することです 。 このファイルでは、次の行の存在を確認する必要があります。

zend_extension = /path/to/xdebug.so
xdebug.default_enable = 0
xdebug.overload_var_dump = 0

行がphp.iniまたはインクルードファイルの1つ（たとえば/etc/php.d/xdebug.ini ）に追加されていない場合、手動でこれを行う必要があります。 次に、Webサーバーを再起動します。

その瞬間から、サイト開発者は、理論的に使用できる新しいxdebug関数を自由に使用できるようになりました。 最初の2つのディレクティブは、エラーが発生したときに関数呼び出しのスタックの拡張表示の機能を無効にし、標準関数var_dump（）をオーバーライドします。 これは開発を支援するすばらしい機能であるにもかかわらず、サイトコードの動作を（わずかではありますが）変更します。 私たちはそれに行くことができません。

分析の開始：関数呼び出しのトレース

サイトを診断して問題領域を識別するための最も重要で便利な方法は、関数呼び出しをトレースすることです。 選択したサイトのページに移動すると、機能の操作に関する統計が収集されます。

• コードの開始時間と終了時間
• 機能順序
• 各関数実行時間
• 各機能によるメモリ消費

この貴重な情報は、コードの「ブレーキ」セクションを確実に決定するのに役立ちます。 さらに、特定の機能によって消費されるメモリの量を判断することも可能です。
トレースを開始する前に、情報の収集を制御し、コード実行のプロセスでより必要なデータを収集するのに役立ついくつかの変数を定義します。

xdebug.collect_paramsは、関数の引数に関する情報を収集するために必要な詳細を示します。 0-最小、情報は収集されません。 1-引数の数とタイプに関する情報が収集されます。 3-引数の意味に関する情報。 4-完全な情報：転送時のタイプ、名前、引数値。 必要な情報が多いほど、トレースに時間がかかります。
xdebug.show_mem_deltaは、各関数が呼び出されたときに、最終レポートにメモリ消費量の違いを反映するかどうかを決定します。
xdebug.trace_enable_triggerは、オンデマンドでトレースを開始する機能を有効または無効にします。
xdebug.auto_traceは、サイトのページにアクセスするたびにトレースの自動開始を有効または無効にします。
xdebug.collect_assignmentsには、レポートに変数の割り当て情報が含まれるか含まれません。
xdebug.collect_includesは、レポートに接続ファイルに関する情報を含めるか含めません。
xdebug.collect_returnは、関数によって返される値に関する情報をレポートに含めるか含めません。
xdebug.trace_output_dirは、レポートがスローされるディレクトリを指定します。
xdebug.trace_output_nameは、レポートのファイル名を生成します。

残りの変数はレポートの視覚表示に関連付けられており、興味はありません。 標準形式は、分析にはまったく受け入れられるようです。

この方法の本質は、管理者が希望する時点でのみトレースを開始することです。 継続的にトレースを有効にすると、コード実行中のリソース消費が増加し、不必要なレポートが大量に作成されるため、受け入れられません。 管理者が要求の実行時にトレース機能を開始することをサーバーに示すには、GETまたはPOST要求でXDEBUG_TRACEパラメーターを渡すか、この名前のCookieを設定する必要があります。 後者の方法は、POST要求を送信することが常に可能であるとは限らず、ほとんど必要ないため、最も好ましいようです。 また、GETを使用する場合、PHPコードを呼び出す前にmod_rewriteまたはエイリアスを使用してサーバーでアドレスバーが処理されることが多いという事実に関連する問題が発生する可能性があります。 したがって、変数は単に宛先に到達しない可能性があります。

転送された変数、接続されたファイル、および関数呼び出し間の消費メモリの差に関する最大情報を収集します。 レポートは/ var / tmpに追加されます。 他の設定はデフォルトです。 その結果、 php.iniに次の行を追加します。

xdebug.trace_enable_trigger = 1
xdebug.auto_trace = 0
xdebug.collect_params = 4
xdebug.show_mem_delta = 1
xdebug.trace_output_dir = / var / tmp


そして、Webサーバーを再起動します。 分析のために、次のコードを使用します。

<?php require "config.inc"; require "class/db.php"; for ($i = 1; $i < 6; $i++) { show_num($i); } $v = array(); alloc_array(1024); $db = DB::Get("mysql", HOST, USER, PASS, NAME); $db->connect(); echo "finished"; function show_num($i) { ($i % 2) ? show_odd($i) : show_even($i); } function show_odd($i) { echo "odd: $i<br>"; } function show_even($i) { echo "even: $i<br>"; sleep(1); } function alloc_array($size) { global $v; for ($i = 0; $i < $size; $i++) { $v[] = $i; } } ?> 

コードはテストケース以外の場合に使用する価値がないと推測するのは簡単ですが、ユーザーがブラウザーでこのコードが担当するページを開こうとしたとしましょう。 ページは10秒以上ロードされています。これは非常に長い時間です。 コードトレースは既にそれに応じて構成されているため、サーバーに今後の要求に対して有効にし、この要求を行うように指示することしかできません。 前述したように、このためには、GETまたはPOSTリクエストでXDEBUG_TRACE変数を設定するか、Cookieを使用して渡す必要があります。 最後のオプション-Cookie転送を選択しました。

通常、特定のドメインのCookie変数は、HTTP Set-Cookieヘッダーを送信してクライアントのブラウザーのサーバーによって設定されるか、JavaScriptを使用してクライアント側で既に設定されています。

サーバーから必要なヘッダーを取得するのは非常に困難です。サイトコードには触れず、サーバー設定を変更するには再起動が必要です。これは定期的な（1回限りの）操作では受け入れられません。 最も正しいオプションは、（クライアント）側でドメインのCookieを設定することです。 Cookieの設定に必要なJavaScriptをサーバーに強制的に提供することはできません。 Set-Cookieヘッダーの場合と同じ理由ですべて。 したがって、私たちは自分でブラウザにクッキーを設定します。 Google Chromeでは、アドレスバーにスクリプトを直接入力することでこれを実行できます。

javascript：document.cookie = "XDEBUG_TRACE = 1"


このスクリプトの実行コンテキストは、サイトに適している必要があります。 つまり、最初にサイトページを開いてから、コマンドを入力する必要があります。
変数を設定したら、ページにリクエストを作成し、リクエストの終了を待ちます。 次に、サーバーで、 / var / tmpディレクトリで対応するトレースファイルを探します。 結果を見てください：

 トレース開始[2012-09-25 11:19:54]
     0.0005 645152 +645152-> {main}（）/var/www/test.phpPoint
     0.0007 649296 +4144-> require（/var/www/config.inc）/var/www/test.php:4
     0.0007 649504 +208-> define（ 'HOST'、'10 .1.1.1 '）/var/www/config.inchaps
     0.0008 649536 +32-> define（ 'NAME'、 'db'）/var/www/config.inc:4
     0.0008 649568 +32-> define（ 'USER'、 'u0'）/var/www/config.inchaps
     0.0008 649600 +32-> define（ 'PASS'、 'ps'）/var/www/config.inc:6
     0.0012 695728 +46128-> require（/var/www/class/db.php）/var/www/test.phphaps
     0.0013 694736 -992-> show_num（$ i = 1）/var/www/test.php:8
     0.0013 694736 +0-> show_odd（$ i = 1）/var/www/test.php:21
     0.0013 694864 +128-> show_num（$ i = 2）/var/www/test.php:8
     0.0013 694864 +0-> show_even（$ i = 2）/var/www/test.php:21
     0.0014 694960 +96-> sleep（1）/var/www/test.php:30
     1.0033 694864 -96-> show_num（$ i = 3）/var/www/test.php:8
     1.0034 694864 +0-> show_odd（$ i = 3）/var/www/test.php:21
     1.0034 694864 +0-> show_num（$ i = 4）/var/www/test.php:8
     1.0034 694864 +0-> show_even（$ i = 4）/var/www/test.php:21
     1.0035 694960 +96-> sleep（1）/var/www/test.php:30
     2.0047 694864 -96-> show_num（$ i = 5）/var/www/test.php:8
     2.0048 694864 +0-> show_odd（$ i = 5）/var/www/test.php:21
     2.0048 695224 +360-> alloc_array（$サイズ= 1024）/var/www/test.php:13
     2.0057 843024 +147800-> DB :: Get（$ type = 'mysql'、$ host = '10 .1.1.1 '、$ user =' u0 '、$ pass =' ps '、$ db =' db '）/ var /www/test.php:15
     2.0057 843664 +640-> absDB-> __コンストラクト（$ host = '10 .1.1.1 '、$ user =' u0 '、$ pass =' ps '、$ db =' db '）/ var / www / class / db php：10
     2.0058 843664 +0-> DB-> __コンストラクト（$ host = '10 .1.1.1 '、$ user =' u0 '、$ pass =' ps '、$ db =' db '）/ var / www / class / db php：36
     2.0058 844000 +336-> DB-> build（）/var/www/class/db.php:19
     2.0058 844016 +16-> absDB-> connect（）/var/www/test.php:16
     2.0058 844368 +352-> mysqli_connect（'10 .1.1.1 '、' u0 '、' ps '、' db '）/var/www/class/db.php:47
    11.0164 8432
トレース終了[2012-09-25 11:20:05] 

レポートの最初の行と最後の行は、それぞれリクエストの開始時間と終了時間を示しています。 この情報から、コードが11秒間実行されたことがわかります。 また、レポートには、ネストを考慮して、コード内のすべての関数の呼び出し順序が表示されます。 最初の列は、関数が呼び出されたときの合計コード実行時間を秒単位で示し、2番目の列は、関数が呼び出されたときのメモリ消費量をバイト単位で示します。 3番目の列は、前の関数によって引き起こされるメモリ消費量の違いです。 残りの列には、関数名、ファイル名、および関数が呼び出された行番号が表示されます。

コードの実行速度が遅くなる原因を理解してみましょう。 まず第一に、ほぼ9秒かかるmysqli_connect（）関数の長い作業が印象的です。 明らかに、リモートサーバーへのアクセスに問題があります。 この関数は、抽象化とクラスのいくつかの層を通して呼び出されることに注意してください。 多くのフレームワークでは、これは一般的なことです。 さらに、ユーザー定義のshow_even（）関数で呼び出されるsleep（）関数で遅延が発生します。

メモリ消費に関しては、ユーザー定義関数alloc_array（）を呼び出した後に140KB以上の急激なジャンプが見られます。また、コード実行の最初に大量のメモリが割り当てられます。

開発者がこれらのレポートをソースコードと比較できるように、すべての関数に渡される引数に関する必要な情報がすべて表示されます。

コードプロファイリング

xdebugがコードのボトルネックを見つけるために提供し、サーバー管理者がサイトコードを変更せずに使用できる別の機会に言及する価値があります。 これはプロファイリングです。 プロファイリングは、Cookie変数の名前を除いて、関数トレースの開始と同じ方法で開始します。 XDEBUG_TRACEの代わりに、XDEBUG_PROFILEが使用されます。 プロファイリングの結果、 vallgrindのcallgrind_annotateユーティリティで認識できるデータを含むファイルを取得し、KDEのKCacheGrindユーティリティまたはWindowsのWinCacheGrindを使用してグラフィカルに表示することもできます。 中でもKCacheGrindは最も機能が豊富です。

オンデマンドのプロファイリングは、関数トレースディレクティブに類似したディレクティブを使用して構成できます。

xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 1
xdebug.profiler_output_dir = / var / tmp