Pages of my site without xdebug load in a few milliseconds, and with xdebug in 5 seconds - at least. And sometimes longer. I don't always need xdebug. I want to turn it off sometimes. And sometimes include. But to do this without changing php.ini and without rebooting the server, but quickly. How can I do this? By pressing a button, for example. Or by commenting on the code. I tried this code:

if (function_exists('xdebug_disable')) { xdebug_disable(); }

But the site still slows down.

  • xdebug_disable - disables only the display of the call stack. it can only be disabled in php.ini - StereoFlo
  • Why do debag on a combat vehicle? Do it on a local tachile and everything will be chic. - And
  • @StereoFlo, can I somehow make it so that I enable xdebug via php code? For example, making a call to a function? xdebug_enable (). I would comment on this line if I don't need xdebug. And uncommented if needed. - user153742 1:34
  • @And, I do on local. page is loaded 9 seconds. sooo boring and slowly it turns out to work. without xdebug for a few ms loads. - user153742
  • What do logs say? Apache or what you have for a web server, see what the logs say and where the memory goes, maybe something sags. - And

3 answers 3

Enabled xDebug, should not slow down. Try the following:

1) try to php.ini , leave the settings to a minimum, only those that you need, for example, if you have enabled profiler, disable it.

2) Until you need a debugger, disable the wiretap in your development environment.

3) If you turned off the wiretap (step 2), and everything is still slow, try to make sure that it is really disabled. In php.ini find out the port to which xdebug sends requests, then check to see if it works telnet localhost {ВАШ_ПОРТ} . If the port is working, the development environment does not correctly terminate the wiretapping.

It seems like everything is simple, but maybe something will help.

    I use a script that edits php.ini and restarts php-fpm. Turning on / off takes a split second.

    Here is an example bash file that allows you to enable or disable xdebug, as well as enable profiler.

     ini_file="/etc/php.d/xdebug.ini" if [ -z $1 ] then if grep -q '\;zend_extension' "$ini_file" then echo 'xdebug is OFF' exit 0 fi if grep -q 'xdebug.profiler_enable=0' "$ini_file" then echo 'xdebug is ON' exit 0 else echo 'xdebug is PROF' exit 0 fi fi if [ 'on' = $1 ] then sed -is/^\;zend_extension/zend_extension/g $ini_file sed -is/^\xdebug.profiler_enable=1/xdebug.profiler_enable=0/g $ini_file systemctl restart php-fpm exit 0 fi if [ 'prof' = $1 ] then sed -is/^\;zend_extension/zend_extension/g $ini_file sed -is/^\xdebug.profiler_enable=0/xdebug.profiler_enable=1/g $ini_file systemctl restart php-fpm exit 0 fi if [ 'off' = $1 ] then sed -is/^zend_extension/\;zend_extension/g $ini_file sed -is/^\xdebug.profiler_enable=1/xdebug.profiler_enable=0/g $ini_file systemctl restart php-fpm exit 0 fi echo 'argument can be "on", "off" or "prof" only' exit 1

    Usage (if this file is named xdebug):

    • xdebug on - includes xdebug
    • xdebug prof - includes xdebug + profiler
    • xdebug off - turns off xdebug and profiler
    • xdebug - displays current status information
    • It can be regarded as a short answer - from the queue of checks. - AK ♦
    • And now it’s even more like a full answer. Yes, the option "without restarting the daemon will not work" is quite a version of the answer. For example, in production, the moveton should be kept constantly debugging on. And on the test server or your dev environment you can switch as much as you like. - AK ♦
    • @AK I am constantly switching, even on LAN. xdebug slows down, but it is not always needed. In phpStorm, even the buttons were invented and hung up on them switching) - KAGG Design
    • With this script, you turn on / off the profiler, and xdebug itself seems to be enabled on you all the time. - StereoFlo 2:12
    • @StereoFlo you are bad at reading this script. I completely disable zend_extension - KAGG Design

    As for me, all the magic scripts that enable and disable xDebug are quite a shamanism, but they do have a place.

    If I had an urgent need to debug a production (well, suddenly) I would use a slightly different approach.

    I could be wrong, but even “turned off” xDebug slows down the work. By off, I mean xdebug.remote_enable = 0. The thing is that it is loaded with a module and works accordingly.

    As for the other approach. If you use php-fpm, I would create two configurations in one of which the module is not loaded, and the other module is loaded. Would launch these configurations on different ports. Further, what we call production - your web server sends to that daemon, which is without a loaded module, but for debugging - you create an additional host on the web server with a different DNS name or simply listen on another port and in this configuration send your request to the second php-fpm daemon which is just with the xdebug module loaded.

    You get a very transparent thing without any megascripts.

    There was a need - raised php-fpm with xDebug, need disappeared - they nailed me. And of course, with additional tools you can limit access to the debug option only on your ip, for example.

    Well, of course, you don’t have any need to overload the services or the server (who is overloading the server?).