View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002076||Xdebug||Step Debugging||public||2022-03-17 10:41||2023-08-01 09:45|
|Status||resolved||Resolution||unable to reproduce|
|Summary||0002076: Application slow when debugger is not running VS Code|
I have been using Xdebug for quite some time now. A few weeks ago i upgraded PHP from 7.4 to 8.0 and i feel like since the update the applications are running slower. Recently i have realised that the application is running fast whenever the debugger in VS Code is running and very slow when it is not running. Disabling Xdebug in php makes the application run fast again.
xdebug.mode = debug
|Tags||No tags attached.|
I can reproduce the issue in my IDE.
 [Step Debug] INFO: Connecting to configured address/port: localhost:9000.
A partly solution is, to set the timeout via xdebug config option to a lower value like 50 ms, which still allows debugging on my system (and reduces wait time from 4s to 1s).
Xdebug does not retry anything. It will try it for every PHP request instead. Does your single page perhaps make 18 sub-requests?
Xdebug will try to connect once for each request. If the network stack is not set-up correctly, then it might need to wait for this (up to) 200ms. In most cases, if there is nothing listening the network stack should reject nearly instantly, and there should be very little slow down. In my local environment, it takes just over half a millisecond:
Can you run an strace to see what it does in your case? You can run your (command line app) with something like, with the log being written to
It does not look as if the 19 connection attempts are triggered by subrequest since I receive the same log, when opening a very simple website like
Strange though - the simple script is NOT delayed, while the website I had tried before (a symfony application) is delayed quite exactly 19 x xdebug.connect_timeout_ms.
So the log is the same, the delay only happens with symfony.
I am on windows here, so I could not follow your proposal with strace, is there something else I can do to help tracking the issue?
I just rechecked, and found my last note is not entirely true.
A simple php script is only 1 x xdebug.connect_timeout_ms delayed and leads to only ONE entry in xdebug.log.
You last comment left me with some questions though:
I don't know specifically, but many frameworks route all requests (even for images etc) through
I don't know Windows, but any normal stack would instantly reject an incoming request to a port that is not open. It is possible that some tools (firewalls, anti virus) gets in the way and instead of instantly declining the incoming connection, it waits until the initiator (Xdebug) times out the connection request.
In my browser dev tool, I have 9 request when I call my symfony main page, only 3 of them are listed in my apache.log.
This still does not fit to the logs somehow.
Another observation (maybe irrelevant), when I turn the vs code debugger on (and everything is fine again), I don't have 19 happy faces in the log, as I was expecting.
I only got one:
So it seems that the subrequests only happen, WHEN the vs code debugger is off.
I also experience this. In my access.log i have two requests:
In my error.log i have:
The network tab in chrome debugger only shows two requests being made (the same ones as in my access.log). If i turn on the debugger in vs code, the problem is gone and the page is rendered in a second instead of almost a minute. Am I correct to assume ONE connection attempt is made at each request to the web server? In my case, all i do is load the wordpress core, and i suppose it probably does run quite a bit of other code, but i see no new requests coming in to my webserver, so in theory nothin would trigger a new connection attempt from xdebug unless through some other internal php mechanism that i'm not aware of.
This is my setup:
I'm still not convinced that there is anything wrong on the Xdebug side here.
I can't reproduce this, and there hasn't been any new information for a while, so I am closing this.
|2022-03-17 10:41||robsangar||New Issue|
|2022-03-23 09:38||Ownerofthisisle||Note Added: 0006248|
|2022-03-25 16:29||derick||Assigned To||=> derick|
|2022-03-25 16:29||derick||Status||new => feedback|
|2022-03-25 16:29||derick||Note Added: 0006256|
|2022-03-31 12:33||Ownerofthisisle||Note Added: 0006265|
|2022-03-31 15:55||derick||Note Edited: 0006265|
|2022-04-07 11:18||Ownerofthisisle||Note Added: 0006268|
|2022-04-11 08:46||derick||Note Added: 0006271|
|2022-04-11 10:18||Ownerofthisisle||Note Added: 0006272|
|2022-07-05 15:55||rthgfbghty||Note Added: 0006343|
|2022-10-05 15:11||derick||Note Added: 0006389|
|2023-08-01 09:45||derick||Status||feedback => resolved|
|2023-08-01 09:45||derick||Resolution||open => unable to reproduce|
|2023-08-01 09:45||derick||Note Added: 0006618|