CODEWITHSUNDEEP
xdebugphpstorm
Will-i-Am-Davidon
Will-i-Am-Davidon

Reputation: 1762

enabling xdebug remote debug makes apache server very slow

If I enable xdebug by settting xdebug.remote_enable=1, the apache server becomes very slow; once I change the setting to 0, it's normal.

I found a same question here: XDebug really slow, but the answer isn't helpful. I didn't enable profiling:

xdebug.profiler_enable=0
xdebug.auto_trace = 0
xdebug.trace_output_dir = /tmp/xdebug
xdebug.trace_output_name = trace.%c

I checked there's nothing under /tmp/xdebug folder.

When xdebug remote debug is enabled and I enable debug listening in PHPStorm, it takes a short while to stop at the breakpoint, but not as slow as disabling phpstorm debug listening.

My environment is: php + apache + xdebug on local centos VM, my mysql db and PHPStorm are on Windows desktop for development. MySQL is not slow.

Appreciate for help.

Upvotes: 68

Views: 52683

Answers (17)

Olivier BLANC
Olivier BLANC

Reputation: 1

I looked for the reason why loading a simple page is extremely slow (more than 15s) when the Symfony toolbar is active and Xdebug is activated in step-by-step mode (xdebug.mode=debug).

This happens from the moment Xdebug is enabled on the browser, regardless of whether listening is enabled on the IDE.

It turns out that the Symfony toolbar is loaded using an XHR request which contains the parameter XDEBUG_IGNORE=1 in order to avoid Xdebug slowing down its loading, but this is only taken into account from the version 3.4.0alpha1 of Xdebug which was released on May 31, 2024 (https://xdebug.org/updates).

At the time of writing, there is no stable version of Xdebug that contains this patch, since the latest version available is 3.4.0beta1 was released on October 4, 2024.

With Xdebug >= 3.4.0alpha1, we go from >=15s to around 200ms to load a basic page with the Symfony toolbar active, which is still much more comfortable and efficient for development.

Additional links:

Upvotes: 0

dag0310
dag0310

Reputation: 53

For me the problem was that xDebug slowed down my PHP requests only when the debugger was not started, because VS Code was apparently waiting for it.

Setting the timeout to zero (xdebug.connect_timeout_ms = 0) fixed the lag for me and still allows me to start the debugger and stop at breakpoints.

This is my full xDebug config in php.ini:

zend_extension = xdebug
xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.connect_timeout_ms = 0

Upvotes: 2

Jörg
Jörg

Reputation: 127

I have the same problem on an Windows 10 machine with VS-Code (Visual Studio Code) IDE and XAMPP for local Wordpress development: PHP takes 10 to 20 times longer for execution when xdebug is activated.

There is a workaround for this problem. In php.ini configure:

xdebug.start_with_request = trigger

and in your PHP-Code use:

xdebug_break();

As a consequence of this, xdebug will start working only if it receives the signal "xdebug_break();" from your PHP code. There will be a breakpoint in the line after that. Then you can continue with step debugging etc.

In VS Code I'm using the PHP extension pack and then start the VS Code debugger with "Listen for xdebug".

Upvotes: 0

Petr Pánek
Petr Pánek

Reputation: 389

For me helped in Xdebug 3 to disable "develop" in xdebug.mode in php.ini.

xdebug.mode=debug,develop

changed to

xdebug.mode=debug

Upvotes: 1

Janne
Janne

Reputation: 1151

Just an headsup for people living in year 2022.

At least on XAMPP with PHP 8.0 & xDebug "xdebug.remote_autostart=1" parameter has been renamed to "xdebug.start_with_request=yes". Commenting this row gave 3x faster rendering speed when browsers xDebug-plugin is disabled. After enabling it's slow as usual, but that's to be expected.

For an example, my Laravel project loads really complex controller-route with dozens of Eloquent queries in 600ms when xDebug is completely disabled on php.ini . When it's activated with "start_with_request" set to false it renders in 1.6 seconds. When debugging is enabled either from plugin or "start_with_request" is set true it takes about 4.5 seconds.

Upvotes: 2

salih0vicX
salih0vicX

Reputation: 1373

In case anyone still struggle with slow xdebug on Windows platform, reducing number of breakpoints worked for me. From whatever reason, each breakpoint slows down debugging ...

Upvotes: 0

Tashi
Tashi

Reputation: 683

For me I had

xdebug.remote_connect_back = 1

which slowed everything and stopped remote debugging from working. Once I remove it, everything works fine.

Upvotes: 0

maccevedor
maccevedor

Reputation: 165

I had the same problem with a docker container and Visual Studio Code , used this 

; disables xdebug traces in error messages
xdebug.default_enable = "Off"

Thanks @tomáš-fejfar

Upvotes: 2

Paul Bönisch
Paul Bönisch

Reputation: 294

For me, Xdebug version 2.7.2 was slow on including vendor's autoload.php Xdebug ersion 2.6.0 was just fine.

Upvotes: 2

Santi Barbat
Santi Barbat

Reputation: 2315

Sometimes if you have other services working in the port 9000, Xdebug will not be able to connect to his server at the port 9000 and it will make it slow because it will get timeout on every request.

Try to change the default port(9000) where xDebug is listening, I used 9090 for the example but you can use whatever free port you have:

xdebug.remote_port=9090

Then remember to change the port where xDebug is listening on you IDE, I'm using Visual Studio Code:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9090,
            "log": true
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9090
        }
    ]
}

Upvotes: 2

MacNeil
MacNeil

Reputation: 81

Also, if you do want to leave xdebug.remote_autostart = 1 enabled all the time, in your Phpstorm settings try increasing the max simultaneous sections. This should reduce hanging and blocks, but will still result in a performance impact based on my experience.

enter image description here

Upvotes: 7

Tomáš Fejfar
Tomáš Fejfar

Reputation: 11217

In my case this was caused by having 

xdebug.remote_autostart = 1

set in php.ini. That causes xdebug to try to connect to remote debugger on every request. I had some PHP handled styles, auto_preppend_file and other PHP files in the request and for each of them it waited approximately 2secs, which added up to sth. like 15 seconds or so. Setting 

xdebug.remote_autostart = 0

solved the problem completely. xdebug connects only when debug cookie is present. Please note you need to remove the debug cookie/param if you are not in debug session for this fix to work.

Here is my config that I use to setup xdebug.

Upvotes: 86

Jovan D.
Jovan D.

Reputation: 101

In my case low performance was caused by having 200+ breakpoints set in PHPStorm which were evaluated on every request by xdebug.

Clearing those breakpoints in PHPStorm increased perfomance from 60 sec to 6 sec per request.

Upvotes: 7

user2992220
user2992220

Reputation: 1112

Experienced also low performance with XDebug (loading Captcha in 6 seconds instead of milliseconds) Remarks on this page got me on the way to identify the cause.

Turned off the profiler and loading time was divided by 3. Still slow, but better already.

xdebug.profiler_enable = 0

Upvotes: 32

gmo
gmo

Reputation: 9000

Just as further reference... in case anyone has the same/similar problem ... (60 sec. timeout)

First double check xdebug.remote_autostart is disabled to avoid the auto connection.
As @LazyOne pointed out, and @Tomáš Fejfar explains as well.

xdebug.remote_autostart
Type: boolean, Default value: 0
Normally you need to use a specific HTTP GET/POST variable to start remote debugging (see Remote Debugging). When this setting is set to 1, Xdebug will always attempt to start a remote debugging session and try to connect to a client, even if the GET/POST/COOKIE variable was not present.

With this, I recover my normal speed when the debug cookie wasn't present...
But!... I still get very slow response (60 sec. timeout) from the server when the cookie was manually activated.

So, after reading the Xdebug Documentation and checking my config,
I find out that I had enable xdebug.remote_connect_back

xdebug.remote_connect_back
Type: boolean, Default value: 0, Introduced in Xdebug > 2.1
If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request. It checks the $_SERVER['REMOTE_ADDR'] variable to find out which IP address to use. Please note that there is no filter available, and anybody who can connect to the webserver will then be able to start a debugging session, even if their address does not match xdebug.remote_host.

So all calls to the server was trying to be debugged, making the server very slow and also insecure.

Disable this option and and verified that I had well-defined xdebug.remote_host pointing to my machine, I got an acceptable response ~1sec. and only when the cookie is enabled.

So in brief, my configuration file end up like this:

zend_extension             = "/absolute/path/to/your/xdebug-extension.so"
xdebug.remote_enable       = 1
xdebug.remote_autostart    = 0
xdebug.remote_connect_back = 0
xdebug.remote_host         = "192.168.1.2"
xdebug.remote_port         = 9000
xdebug.remote_handler      = "dbgp"
xdebug.remote_mode         = req
xdebug.remote_log          = "/tmp/xdebug.log"

Note: I made this changes in etc/php5/conf.d/xdebug.ini file and not in php.ini

Edit:
As @Riimu & @jdunk point it out thanks to both, you may want to set also:
* see comments for details

xdebug.remote_cookie_expire_time = 0
// or
xdebug.remote_cookie_expire_time = -9999

Upvotes: 29

Jean-Pierre Schnyder
Jean-Pierre Schnyder

Reputation: 1934

I am using PHPStorm 7.1 and the Apache server installed by Xampp 1.8.2, all that under Windows 8.1. I did experience slow interoperability between Chrome and PHPStorm in debug mode when having breakpoints set.

Speed was notably improved by installing the last version of the XDebug dll (use the XDebug wizard to determine which version to download), copy the dll in your php/ext dir and change the php.ini so the new XDebug dll will be loaded. Stopstart Apache and see the difference.

I could verify that a similar performance gain occured when debugging a webapp with Eclipse (Juno with PDT) using the internal Eclipse web browser.

Upvotes: 3

Derick
Derick

Reputation: 36784

It's likely that there are some networking timeouts that happen here. The best way to find out what's going wrong is to try to debug a command line script. If that still has the same issue, then use strace to see what it is hanging on:

export XDEBUG_CONFIG="idekey=yourname"
strace -tt -o /tmp/strace.log php full/path/to/script.php

Then have a look at /tmp/strace.log and see where the slow down happens.

Upvotes: 1

Related Questions