Will Enabling Xdebug on a Production Server Make PHP Slower

Will enabling XDebug on a production server make PHP slower?

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.

Php slower with XDebug activated but no debug session running

Its likely your profiler,

xdebug.profiler_enable = 1
xdebug.profiler_enable_trigger = off

From the manual

xdebug.profiler_enable_trigger
Type: integer, Default value: 0
When this setting is set to 1, you can trigger the generation of profiler files by using the XDEBUG_PROFILE GET/POST parameter, or set a cookie with the name XDEBUG_PROFILE. This will then write the profiler data to defined directory. In order to prevent the profiler to generate profile files for each request, you need to set xdebug.profiler_enable to 0.

So its always making profiles, Which will take much longer, You should only need to profile when you need to know the results of a profile

The debugger at most will try to open a socket. Its allows requests from GET POST and COOKIE. and when you connect, it sets a cookie for 1 hour by default which makes the debugger try and connect to a port each time you request after for 1 hour

XDebug on Hosting - Security?

xdebug is perfectly safe on a remote instance as long as you set the xdebug.remote_host variable. Otherwise it is a MAJOR secuirty problem because it would allow the attacker to view any variable in memory during runtime. It could be used to obtain your mysql login or any other secret variables you may have.

edit: A VPN is a good solution to keep leaking sensitive data over the net in plain text.

PHP composer xdebug warning

I do not want to disable xdebug when I am developing. Just wanted to confirm that running xdebug in dev environment should have no impact on the composer installing libraries/performance of the app on the production server.

There is a huge impact of just loading Xdebug. It slows the Composer run down by 3x or 4x, even when the profiling feature is not enabled.

In other words: xdebug is invaluable for debugging, but increases the memory used and processing time of Composer.

How to disable Xdebug for Composer runs?

My suggestion is to write a little invocation helper for running Composer.

The helper is a bash or batch script calling PHP with a custom php.ini, especially configured for Composer. Lets call it: php.ini-composer.

You could copy your current php.ini and adjust it for the Composer run, by removing xdebug or commenting it out, like so: ;zend_extension = "/path/to/my/xdebug.so".

While you are at it: setting memory_limit=-1 is helpful, too.

The full command looks like so on Windows: php.exe -c php.ini-composer composer.phar %*

Just clone the idea for a bash script.

And you may find the full answer to your question in the Composer FAQ.

https://getcomposer.org/doc/articles/troubleshooting.md#xdebug-impact-on-composer

It was added/updated just a few hours ago.

Some alternatives (instead of using seperate ini file) are also mentioned here.

PDOStatement- execute 14 times slower on production server than on development server

I finally figured it out today! The problem was that the temporary tables were not created in memory on the production server. I don't know why since the config files clearly states it should but I solved the problem by adding ENGINE = MEMORY to all CREATE TEMPORARY TABLE calls.

E.g.:

CREATE TEMPORARY TABLE group_members (id INT PRIMARY KEY) ENGINE = MEMORY

Will Enabling Xdebug on a Production Server Make PHP Slower