问题
The title pretty much says it all...is it a bad idea ? I'd like to have the enhanced debug messages that XDebug provides on the server.
[edit] Just to make things clear. I'm aware there are security risks involved. Perhaps I should complement my question and give more precise reasons why I would want to do this.
Our production server hosts a testing platform also. Sometimes we use it to test things on a environment as close to production as possible. The main thing I'm looking for is using XDebug's enhanced var_dump().
This is not an app server for high traffic apps and performance is not that big of an issue. I was just curious if performance would be noticeably impacted by XDebug.
Besides, I guess I could enable it only for the VirtualHost that defines the testing sites.
回答1:
Besides the obvious fact that debug messages cannot be displayed in a application that is already in production, and also the fact that I don't know why would you like that, there a couple of things really bad about it.
The first one is that when you add debugging behavior to your server, the debug engine "attaches" to the PHP process and receive messages of the engine to stop at breakpoints, and this is BAD, because introduces a high performance blow to have another process stopping or "retaining" the PHP parser.
Another big issue is that when a debugger is installed, at least most of them, they tend to have the nasty habit of opening ports in your server, because they are not intended for production environments, and as you may know, any software that opens ports in your server is opening a door for any hacker around.
If you need to have debugging in your code, then in your application, implement a debugging system, if is not available, since most frameworks have this built in. Set a configuration value, say DEBUG_ENABLED and when throwing exceptions, if is not enabled, redirect to a petty page, else to a ugly page with debugging information, but take good care of what debugging information you display in your server. I hope this clarifies everything.
EDIT As apparently my response is not documented enough, you should check these sources
- PHPs XDebug tracing overhead in production
- Careful: XDebug can skew your performance numbers
Finally, there is one thing I didn't said as I thought it was sort of implicit: It's common sense not do it! You don't put debugging instruments on your production server for the same reason that you keep them on a different environment, because you need to keep unnecessary stuff away from it. Any process running on a server, no matter how light it is, will impact your performance.
回答2:
Slow down by factor 4
I made some tests just enabling the module, without actually debugging, makes slows down a request on my development machine from 1 second to around 4 seconds
回答3:
Why on earth do you want something like that? Debug before you deploy to production. It will make the app slower.
回答4:
Removing xdebug completely (even when it was not enabled) gave us 50% in page load boost (down from 60ms to 30ms). We had xdebug sitting "dormant" (waiting for trigger). We thought that since it's dormant it won't cause any harm, but boy were we wrong.
We commented out the zend_extension line in the php config at around 21:43. Average load dropped from 0.4 to 0.2 per core as well:
回答5:
You should never keep that on production.
Your application shoud never need to print out "those nice debug messages", as they are not nice at all to your users. They are a sign of poor testing and they will kill user's trust, especially in a enterprise/ecommerce environment.
Second, the more detailed technical information you reveal, the more you are likely to get hacked (especially if you are already revealing that there ARE in fact problems with your code!). Production servers should log errors to files, and never display them.
Speed of execution is your least concern, anyway it will be impacted by it, as will memory.
回答6:
Xdebug is for adding full stack traces to error logs, that is the display_errors ini value, which of course should be Off (even in development I dont want this). It does not allow remote attachment to a debugger unless you enable the remote_attach ini setting. While it is slower, if you have a PHP mystery error like Max memory allocated or Segmentation fault, this is the only way you will see where it actually hapenned.
回答7:
You could always clone your live server with the exactly same configuration, except that it wouldn't be public. Then you can install XDebug on it and debug things with the almost exactly the same conditions (well, load will be different between real life and the clone, but the rest will be the same). In that case you debug things on a live environment, but real live is not affected.
Note: Obviously it does not apply to anyone. Not everyone can easily clone a server. If you use cloud services like AWS etc. it would be very easy. If you use server configuration tools like Ansible, Chef, Puppet for building your server this is a piece of cake as well.
回答8:
You should never display debug error messages on a production server. It's ugly for your users and also a security risk. I'm sure it will make it a little slower too.
回答9:
You can use XDebug in production if you "do it right". You can enable the extension in a "dormant" mode that is only brought to live through requests that go through a specific HOSTS name. Se details here:
http://www.drupalonwindows.com/en/content/remote-debugging-production-php-applications-xdebug
来源：https://stackoverflow.com/questions/3522182/will-enabling-xdebug-on-a-production-server-make-php-slower