37

タイトルはほとんどそれをすべて言います...それは悪い考えですか?XDebug がサーバーで提供する強化されたデバッグ メッセージが必要です。

[編集] わかりやすくするために。セキュリティ上のリスクが伴うことは承知しています。おそらく、私は自分の質問を補足し、なぜこれをやりたいのか、より正確な理由を述べるべきです.

私たちの実稼働サーバーは、テスト プラットフォームもホストしています。可能な限り本番環境に近い環境でテストするために使用することもあります。私が探している主なものは、XDebug の Enhanced を使用することですvar_dump()

これはトラフィックの多いアプリ用のアプリ サーバーではなく、パフォーマンスはそれほど大きな問題ではありません。パフォーマンスがXDebug によって著しく影響を受けるかどうかに興味がありました。

また、テスト サイトを定義する VirtualHost に対してのみ有効にできたと思います。

4

11 に答える 11

45

すでに本番環境にあるアプリケーションではデバッグメッセージを表示できないという明らかな事実と、なぜそれが必要なのかわからないという事実に加えて、それについて本当に悪いことがいくつかあります。

1つ目は、サーバーにデバッグ動作を追加すると、デバッグエンジンがPHPプロセスに「接続」し、エンジンのメッセージを受信して​​ブレークポイントで停止することです。これは、別のプロセスを実行するための高性能の打撃をもたらすため、悪いことです。 PHPパーサーを停止または「保持」します。

もう1つの大きな問題は、デバッガーがインストールされている場合、少なくともほとんどのデバッガーは、実稼働環境や、ご存知のように、開くソフトウェアを対象としていないため、サーバーでポートを開くという厄介な習慣を持っている傾向があることです。サーバーのポートは、周りのハッカーに門戸を開いています。

コードでデバッグを行う必要がある場合は、アプリケーションでデバッグシステムを実装します。ほとんどのフレームワークにはデバッグシステムが組み込まれているため、利用できない場合はデバッグシステムを実装します。DEBUG_ENABLEDなどの構成値を設定し、例外をスローする場合は、有効になっていない場合は、ささいなページにリダイレクトします。そうでない場合は、デバッグ情報を含む醜いページにリダイレクトしますが、サーバーに表示するデバッグ情報には十分注意してください。これですべてが明らかになることを願っています。

編集どうやら私の応答は十分に文書化されていないので、これらのソースを確認する必要があります

最後に、それは一種の暗黙のことだと思ったので、私が言わなかったことが1つあります。それは、それをしないのが常識です!デバッグ機器を別の環境に保管するのと同じ理由で、本番サーバーにデバッグ機器を配置しないでください。不要なものをサーバーから遠ざける必要があるためです。サーバー上で実行されているプロセスは、それがどれほど軽量であっても、パフォーマンスに影響を与えます。

于 2010-08-19T13:40:50.943 に答える
17

ファクター4で減速

実際にデバッグせずにモジュールを有効にするだけでいくつかのテストを行いましたが、開発マシンでのリクエストが1秒から約4秒に遅くなります

于 2012-09-05T09:44:47.550 に答える
4

いったいなぜそんなものが欲しいの?本番環境にデプロイする前にデバッグしてください。アプリの速度が低下します。

于 2010-08-19T13:23:28.270 に答える
1

公開されないことを除いて、まったく同じ構成でライブサーバーをいつでも複製できます。次に、XDebug をインストールして、ほぼ同じ条件でデバッグを行うことができます (まあ、実物とクローンでは負荷が異なりますが、残りは同じです)。その場合、ライブ環境でデバッグしますが、実際のライブには影響しません。

注: もちろん、誰にでも当てはまるわけではありません。誰でも簡単にサーバーのクローンを作成できるわけではありません。AWSなどのクラウドサービスを使えばとても簡単です。Ansible、Chef、Puppet などのサーバー構成ツールを使用してサーバーを構築する場合、これも簡単です。

于 2016-10-18T08:14:17.407 に答える
1

Xdebug は、完全なスタック トレースをエラー ログに追加するためのものです。つまり、display_errors ini 値であり、もちろんオフにする必要があります (開発中であっても、これは望ましくありません)。remote_attach ini 設定を有効にしない限り、デバッガーへのリモート接続は許可されません。速度は遅くなりますが、割り当てられた最大メモリやセグメンテーション違反などの PHP の謎のエラーが発生した場合、これが実際に発生した場所を確認する唯一の方法です。

于 2012-11-15T00:02:07.100 に答える
1

それを本番環境に保持しないでください。

あなたのアプリケーションは、「これらの素敵なデバッグ メッセージ」を出力する必要はありません。これらはテストが不十分であることを示しており、特にエンタープライズ/e コマース環境では、ユーザーの信頼を失うことになります。

第 2 に、公開する技術情報が詳細になるほど、ハッキングされる可能性が高くなります (特に、実際にコードに問題があることを既に公開している場合は!)。運用サーバーはエラーをファイルに記録し、表示しないようにする必要があります。

とにかく、メモリと同様に、実行速度は影響を受けます。

于 2010-08-19T13:28:43.187 に答える
1

これが古い投稿であることは承知していますが、Xdebug の問題は 10 年経った今でも残っているため、関連するバグ レポート (WONTFIX NOTABUG としてクローズ) を参照したいと思います: https://bugs.xdebug.org/view .php?id=1668

概要:

xdebug をインストールするだけで (Linux @least では) サイト上のすべての php が遅くなり、すべてのフラグがオフに設定されていても、ヒット数は 2 倍から 20 倍になります。 本番環境では xdebug をインストールしないでください。できれば、邪魔にならないデバッグ オプションを調べてください。

于 2020-04-06T08:23:23.470 に答える
0

本番サーバーでデバッグ エラー メッセージを表示しないでください。ユーザーにとって見苦しく、セキュリティ上のリスクもあります。それも少し遅くなると思います。

于 2010-08-19T13:27:14.650 に答える