1

TLDR:

When Xdebug is loaded as a PHP module, it takes a heavy performance toll even when completely disabled. [1]

Is it possible to load Xdebug module without ANY performance overhead?

Considering, of course, that it HAS a performance overhead when it's actively debugging (through the presence of a debug cookie in HTTP requests, or, in CLI, through a series of -dxdebug parameters to enable it) or while profiling.

Full explanation:

I was investigating poor performance issues when running an integration test suite. It was taking 2 minutes to run the whole suite. I had disabled everything there was to disable on Xdebug, until I finally decided to completely remove the module itself from PHP. When I did that, the integration suite took 56 seconds to run. Almost twice as fast.

I started digging into it and saw that this is a common issue. Again [1] as a reference. These are the settings that I'm using:

xdebug.remote_autostart         = Off
xdebug.default_enable           = Off
xdebug.profiler_enable_trigger  = Off
xdebug.remote_enable            = Off
xdebug.remote_handler           = dbgp
xdebug.remote_port              = 9000
xdebug.idekey                   = PHPSTORM
xdebug.remote_log               = /var/log/php/xdebug.log

And this is the PHP / Xdebug version:

PHP 7.4.2 (cli) (built: Feb  1 2020 19:47:36) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.2, Copyright (c), by Zend Technologies
    with Xdebug v2.9.2, Copyright (c) 2002-2020, by Derick Rethans

I saw this difference in PHP CLI.

[1] Related:

Lucas Bustamante
  • 15,821
  • 7
  • 92
  • 86
  • What is the purpose of having Xdebug: actual debugging or for code coverage reports (e.g. PHPUnit)? If 2nd -- try another engine (e.g. PCOV or PHPDBG) -- they seem to be much faster for doing that (if your editor/IDE supports this, e.g. PhpStorm supports from 2020.1, to be released soon: https://blog.jetbrains.com/phpstorm/2020/01/phpstorm-2020-1-early-access-program-is-now-open/#code_coverage_with_pcov_and_phpdbg). – LazyOne Apr 02 '20 at 10:29
  • Other than that: just having Xdebug module loaded (and not doing anything, just enabled to look for possible "debug me" flags) will slow down code execution, around 2x (based on my benchmarks from about 4 years ago or so). – LazyOne Apr 02 '20 at 10:29
  • You still need Xdebug loaded during PHP startup (especially if script is served by a web server, where you cannot pass extra params to load xdebug just for this request like you may do with CLI script). P.S. If you need to debug and you do not want to use any "debug me" flags (cookie, GET/POST params etc), you may invoke Xdebug from PHP code -- `xdebug_break();` -- will act as programmatic breakpoint and will initiate debug session as if "debug me" flag is present. – LazyOne Apr 02 '20 at 10:33
  • @LazyOne I have Xdebug as a development and debugging tool, which I'd like to activate when given certain debug flags. If these debug flags are not provided, I'd expect it to not take any performance toll. – Lucas Bustamante Apr 02 '20 at 15:26
  • 1
    Just having Xdebug loaded will introduce certain slow down in PHP code execution. You can workaround that for CLI scripts -- just load Xdebug dynamically when needed with `-z` parameter AFAIK (PhpStorm can do that, for example -- it will pass such params when you click "Debug" for a CLI scipt). For web server, since you do not launch/control PHP directly, you would need to manually (or by using some automation script) enable/disable Xdebug in php.ini and restart web server, which is not that convenient. – LazyOne Apr 02 '20 at 15:47
  • @LazyOne That worked for CLI, thank you. Do you want to add that as an answer? – Lucas Bustamante Apr 02 '20 at 17:05

1 Answers1

3

Okay, I got it, at least for PHP CLI.

This will disable Xdebug on web requests, but you will be able to run CLI commands with and without Xdebug. If you are writing many automated tests, it might be worth it.

First, disable Xdebug completely. Run php --version to confirm you don't see a line like this "with Xdebug v2.9.2, Copyright (c) 2002-2020, by Derick Rethans".

Then, run php -i | grep ^extension_dir to find out where your PHP extensions are stored. CD into that folder and check if you can find xdebug.so there.

Now, run php with the parameter -dzend_extension=YOUR_XDEBUG.SO_PATH to have Xdebug loaded. Example:

php --version

Gives:

PHP 7.4.2 (cli) (built: Feb  1 2020 19:47:36) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.2, Copyright (c), by Zend Technologies

php -dzend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so --version

Gives:

PHP 7.4.2 (cli) (built: Feb  1 2020 19:47:36) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.2, Copyright (c), by Zend Technologies
    with Xdebug v2.9.2, Copyright (c) 2002-2020, by Derick Rethans

In my case, I have made it an bash alias, with a few more parameters for a more granular control:

alias phpx='PHP_IDE_CONFIG="serverName=someServerNameInPHPStorm" php -dzend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so -dxdebug.remote_autostart=1 -dxdebug.remote_enable=1 -dxdebug.default_enable=1 -dxdebug.remote_connect_back=1 -dxdebug.remote_handler=dbgp -dxdebug.remote_port=9000 -dxdebug.idekey=PHPSTORM -dxdebug.remote_host=127.0.0.1';

So I use it like: phpx run_something.php to run with Xdebug, and php run_something.php without, for optimal performance.

Thanks @LazyOne for the tip, and I hope Xdebug fixes this performance issue, because as I said, this workaround won't work for web requests.

Lucas Bustamante
  • 15,821
  • 7
  • 92
  • 86