Will enabling XDebug on a production server make PHP slower?

Question

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.

Lutestring

jtreminio.com/blog/developing-at-full-speed-with-xdebug – Stelle

Answer 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.

Werner

Thanks for your answer. I've edited my question because many answers mentioned what you (rightly) suggest: security issues and in general bad practice. – Lutestring

This answer is pure FUD, without evidence of a security hole in xdebug, or of performance problems. For all I know this answer is right -- but it provides no evidence to back up its assertions. With the right settings (e.g. display_errors off, and no remote debugging), I don't on the face of it see why XDEBUG (which is after all compiled code) would perform more poorly than a custom solution. – Estop

@GeorgeLund are you happy with the links there? Also, I think that putting debugging tools on a production site is something that you should avoid, just because it makes sense... – Werner

Thanks! I'm quite grumpy that PHP doesn't natively manage to produce full stack traces on exceptions without XDebug (any other options?) -- other languages don't have that problem. (Heck, even with C you can get a core dump in an extreme case!) – Estop

No worries, you did had a point, the answer didn't had any backing up ;) Admittedly, I haven't been much involved with PHP for some time but the concept applies to most server side languages. – Werner

Note that these links just discuss the performance impact of using xdebug in production and don't give any indication that this is a bad idea. The first link says "XDebug is a great tool, an a good alternative for the commercial Zend Server, however it is not suitable for production environments as Zend server is. " It's not "wrong" to have access to more debugging information on live and there are time where there are subtle bugs that only come out on live. We happen to use kohana which has a nice html stack trace builder so it's not an issue for us. – Blueprint

Answer 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

Spurt

What sorts of tests? What parts of PHP were slowed down? What was the test framework? – Tinsmith

@Aredridel No framework. I had a Magento shop and called one page and compared the results in the Chrome developer tools networking tab. Did not investigate which parts were slowed down. – Spurt

Ah, so a lot of possibilities for variability. – Tinsmith

I just run into this issue, my code is faster if my debogguer is running than if it doesn't. From <1s with IDE (PhpStorm) debug enabled to 4/5sec disabled/IDE closed. – Torpedoman

@Torpedoman (Just for the sake of future readers) this is because you did not disable xdebug remote and it triend to connect to your ide (which was closed and did not respond). – Idealize

Answer 3

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:

Ajit

See also recent bug reports: Even more slowdown after upgrading from Xdebug 2.9.x to 3.0.1: bugs.xdebug.org/view.php?id=1911 , github.com/oerdnj/deb.sury.org/issues/1523 – Armandarmanda

I just fell for the same issue. Can confirm this makes an insane difference. – Walkover

Answer 4

Why on earth do you want something like that? Debug before you deploy to production. It will make the app slower.

Exportation

Because production environments are where interesting, critical faults happen. – Tinsmith

well you should use vagrant to replicate your live environment so you can develop locally, but with the same environment settings. You can then replicate the live environment vagrant on staging so you can debug your app before pushing it to a production environment. You shouldn't ever push code to live/production that you dont know works – Helminthology

@JamesKirkby generally I agree, but there are times where you might need to maybe mimic the production environment in a staging/production hybrid for instances where you are dealing with an issue that only happens say, behind a load balancer on aws and have variables such as an rds connected, etc and don't know where the issue is stemming from. but yeah, just no to xdebug on live. – Catholicize

Answer 5

I know this is an old post, but since the issue with Xdebug is still there 10 years on, I'd like to point to the relevant bug report (closed as WONTFIX NOTABUG): https://bugs.xdebug.org/view.php?id=1668

Tl;dr:

Just installing xdebug will (on linux @least) slow all php on the site to a crawl, with hits anywhere from 2x to 20x, even if all flags are set to OFF. DO NOT INSTALL xdebug IN PRODUCTION - EVER. Better yet, investigate less intrusive debug options.

Thermionics

Answer 6

Xdebug 3

XDebug 3 now allows an option to disable it to get near 0 overhead: https://xdebug.org/docs/install#mode

You can use config below in production to have xdebug installed with close to 0 overhead:

[xdebug]
xdebug.mode=off

Nothing is enabled. Xdebug does no work besides checking whether functionality is enabled. Use this setting if you want close to 0 overhead.

Graptolite

Answer 7

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.

Lecky

That's what I thought... Actually the only feature I wanted is the enhanced var_dump() formatting. I'm aware there's a security risk as well... – Lutestring

"enabling xdebug" doesn't mean "display error messages to the user" – Tinsmith

Answer 8

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.

Shore

"Xdebug is for adding full stack traces to error logs" -> nope; Xdebug is for debugging and profiling. It can also provide stack traces in error messages, but that's not its main purpose. "It does not allow remote attachment to a debugger unless you enable the remote_attach ini setting" -> there is not such thing like a "remote_attach" ini setting; maybe you meant xdebug.remote_enable. Finally, this is more a comment than an answer. – Desmarais

Answer 9

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.

Bobsledding

Answer 10

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.

Se

It's certainly not a security risk if configured properly, e.g. limiting access to the local interface and hooking up via SSH tunnel only or profiling into a inaccessible directory. Besides, xdebug is not showing debug messages to the user. It either generates traces or provides a debug interface, but both don't affect the user experience, not even if an error occurs. The only legit contradiction is the performance penalty since the profiler will add overhead to every single function call and may prevent certain optimizations. (Especially with modern runtime compilers like Facebooks HipHop) – Unsaddle

Answer 11

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

Pavla

Even when not "enabled" simply having the xdebug extension available will add massive performance overhead. It hooks directly into zend engine even if not enabled – Thiosinamine

Answer 12

I tested the performance impact using this php benchmark tool. Disclaimer I built the tool.

The answer is the xdebug module significantly slows down code execution: from 2x to 7x times depending on the test. Here are my results:

# env information
php version        :     7.4.5
platform           : WINNT x64

# disable xdebug extension in php.ini
$ php src/benchmark.php --iterations 1000 --time-per-iteration 50 --save xdebug_off

# enable xdebug extension
$ php src/benchmark.php --iterations 1000 --time-per-iteration 50 --save xdebug_on

# compare
$ php src/compare.php --file1 benchmark_xdebug_off_20201127-0946.txt --file2 benchmark_xdebug_on_20201127-0939.txt
------------------------------------------------
test_math                  OFF       ON
mean               :      3762      531   -85.9%
median             :      4226      568   -86.6%
mode               :      4655      596   -87.2%
minmum             :       918      188   -79.5%
maximum            :      4722      612   -87.0%
quartile 1         :      3081      490   -84.1%
quartile 3         :      4580      595   -87.0%
IQ range           :      1498      105   -93.0%
std deviation      :       984       87   -91.1%
normality          :     11.0%    11.0%
------------------------------------------------
test_strings
mean               :      1419      677   -52.3%
median             :      1521      688   -54.7%
mode               :      1580      974   -38.4%
minmum             :       537       90   -83.2%
maximum            :      1629     1071   -34.3%
quartile 1         :      1319      452   -65.7%
quartile 3         :      1582      892   -43.6%
IQ range           :       262      440    67.8%
std deviation      :       226      248     9.8%
normality          :      6.6%     6.6%
------------------------------------------------
test_loops
mean               :      8131     1208   -85.1%
median             :      8617     1240   -85.6%
mode               :      9109     1407   -84.6%
minmum             :      3167      589   -81.4%
maximum            :      9666     1435   -85.2%
quartile 1         :      7390     1116   -84.9%
quartile 3         :      9253     1334   -85.6%
IQ range           :      1863      217   -88.3%
std deviation      :      1425      164   -88.4%
normality          :      5.6%     5.6%
------------------------------------------------
test_if_else
mean               :    279630    31263   -88.8%
median             :    293553    31907   -89.1%
mode               :    303706    37696   -87.6%
minmum             :    104279    12560   -88.0%
maximum            :    322143    37696   -88.3%
quartile 1         :    261977    28386   -89.2%
quartile 3         :    307904    34773   -88.7%
IQ range           :     45927     6387   -86.1%
std deviation      :     39034     4405   -88.7%
normality          :      4.7%     4.7%
------------------------------------------------
test_arrays
mean               :      5705     3275   -42.6%
median             :      5847     3458   -40.9%
mode               :      6040     3585   -40.6%
minmum             :      3366     1609   -52.2%
maximum            :      6132     3645   -40.6%
quartile 1         :      5603     3098   -44.7%
quartile 3         :      5965     3564   -40.3%
IQ range           :       361      465    28.8%
std deviation      :       404      394    -2.5%
normality          :      2.4%     2.4%
------------------------------------------------

Pfaff