本番サーバーでXDebugを有効にすると、PHPが遅くなりますか？
タイトルはほとんどそれをすべて言います...それは悪い考えですか？ XDebugがサーバー上で提供する拡張デバッグメッセージが欲しいのですが。
[編集]物事を明確にするためだけに。セキュリティ上のリスクがあることは承知しています。おそらく、私の質問を補足し、これを実行したい理由をより正確に説明する必要があります。
当社の本番サーバーは、テストプラットフォームもホストしています。場合によっては、可能な限り本番環境に近い環境でテストするために使用します。私が探している主なものは、XDebugの拡張されたvar_dump()を使用することです。
これはトラフィックの多いアプリ用のアプリサーバーではなく、パフォーマンスはそれほど大きな問題ではありません。 XDebugによってパフォーマンスが著しく影響を受けるかどうかだけが気になりました。
その上、テストサイトを定義するVirtualHostに対してのみ有効にできると思います。
すでに本番環境にあるアプリケーションではデバッグメッセージを表示できないという明らかな事実と、なぜそれが必要なのかわからないという事実に加えて、それについて本当に悪いことがいくつかあります。
1つ目は、サーバーにデバッグ動作を追加すると、デバッグエンジンがPHPプロセスに「接続」し、エンジンのメッセージを受信してブレークポイントで停止することです。これは悪いことです。別のプロセスがPHPパーサーを停止または「保持」するために、高性能の打撃を導入します。
もう1つの大きな問題は、デバッガーがインストールされると、少なくともそれらのほとんどは、実稼働環境や、ご存知のように、開くソフトウェアを対象としていないため、サーバーでポートを開くという厄介な習慣を持っている傾向があることですサーバーのポートは、周りのハッカーに門戸を開いています。
コードでデバッグを行う必要がある場合は、アプリケーションでデバッグシステムを実装します。ほとんどのフレームワークにはデバッグシステムが組み込まれているため、利用できない場合はデバッグシステムを実装します。DEBUG_ENABLEDなどの構成値を設定し、例外をスローする場合は、有効になっていない場合は、ささいなページにリダイレクトするか、デバッグ情報のある醜いページにリダイレクトしますが、サーバーに表示するデバッグ情報には十分注意してください。これですべてが明らかになることを願っています。
[〜＃〜] edit [〜＃〜]どうやら私の応答は十分に文書化されていないので、これらのソースを確認する必要があります
最後に、それは一種の暗黙のことだと思ったので、私が言わなかったことが1つあります。それは、それをしないのが常識です！デバッグ機器を別の環境に保管するのと同じ理由で、デバッグ機器を本番サーバーに配置しないでください。不要なものをサーバーから遠ざける必要があるためです。サーバー上で実行されているプロセスは、それがどれほど軽量であっても、パフォーマンスに影響を与えます。
ファクター4で減速する
実際にデバッグせずにモジュールを有効にするだけでいくつかのテストを行いましたが、開発マシンでのリクエストが1秒から約4秒に遅くなります
いったいなぜそんなものが欲しいの？本番環境にデプロイする前にデバッグしてください。アプリの速度が低下します。
Xdebugを完全に削除すると（有効になっていない場合でも）、ページの読み込みが50％向上しました（60ミリ秒から30ミリ秒に短縮）。 xdebugを「休止」状態（トリガーを待機中）にしました。休眠中なので害はないと思っていたのですが、男の子は間違っていました。
21:43頃にphp設定のzend_extension行をコメントアウトしました。コアあたりの平均負荷も0.4から0.2に低下しました。
ライブサーバーは、公開されないことを除いて、まったく同じ構成でいつでも複製できます。次に、XDebugをインストールして、ほぼ同じ条件でデバッグできます（実際の負荷とクローンでは負荷が異なりますが、残りは同じです）。その場合、ライブ環境でデバッグしますが、実際のライブは影響を受けません。
注：明らかに、それは誰にも適用されません。誰もがサーバーのクローンを簡単に作成できるわけではありません。 AWSなどのクラウドサービスを使用する場合、それは非常に簡単です。サーバーの構築にAnsible、Chef、Puppetなどのサーバー構成ツールを使用する場合、これも簡単です。
あなたはそれを本番環境で維持してはいけません。
アプリケーションは「これらのNiceデバッグメッセージ」を印刷する必要はありません。ユーザーにとってはまったくNiceではないからです。これらは不十分なテストの兆候であり、特にエンタープライズ/ eコマース環境ではユーザーの信頼を失います。
次に、明らかにする技術情報が詳細であるほど、ハッキングされる可能性が高くなります（特に、コードに実際に問題があることをすでに明らかにしている場合はなおさらです）。本番サーバーはエラーをファイルに記録する必要があり、決して表示しないでください。
実行速度はあなたの最も懸念事項ではありませんが、とにかくそれはメモリと同様にそれによって影響を受けます。
Xdebugは、エラーログにフルスタックトレースを追加するためのものです。つまり、display_errors ini値であり、もちろんオフにする必要があります（開発中でもこれは必要ありません）。 remote_attach ini設定を有効にしない限り、デバッガーへのリモート接続は許可されません。速度は遅くなりますが、割り当てられた最大メモリやセグメンテーション違反などのPHPミステリーエラーがある場合は、これが実際に発生した場所を確認する唯一の方法です。
「正しく実行」すれば、本番環境でXDebugを使用できます。特定のHOSTS名を経由するリクエストを通じてのみ有効になる「休止」モードで、拡張機能を有効にできます。詳細はこちら：
http://www.drupalonwindows.com/en/content/remote-debugging-production-php-applications-xdebug
本番サーバーにデバッグエラーメッセージを表示しないでください。これはユーザーにとって醜いものであり、セキュリティ上のリスクもあります。少し遅くなると思います。