Jump to content

XDEBUG slowing things down considerably (Wampserver)


SiNNuT
 Share

Recommended Posts

This afternoon i was setting up a new laptop with Win7 64bits. Having used it in the past with no problems i decided to use Wampserver 2.5 to setup my webdev environment. Having set up an existing project and a vanilla PW install i noticed that some front-end pages took quite long to respond/render. After logging in i also noticed this in the back-end. Especially opening a template edit page performed bad, with a noticeable 2 to 3 seconds delay in the response. This was not at all the case with the live site running the same code base.

After some hair-pulling i discovered that it was xdebug slowing things down. In Wampserver it comes bundled with the following settings in php.ini (to which i added the max_nesting_level because the default 100 will cause problems in PW) :

; XDEBUG Extension
zend_extension = "c:/wamp/bin/php/php5.5.12/zend_ext/php_xdebug-2.2.5-5.5-vc11-x86_64.dll"

;xdebug
xdebug.remote_enable = off
xdebug.profiler_enable = off
xdebug.profiler_enable_trigger = off
xdebug.profiler_output_name = cachegrind.out.%t.%p
xdebug.profiler_output_dir = "c:/wamp/tmp"
xdebug.show_local_vars=0
xdebug.max_nesting_level = 200

After commenting out all of the above, basically disabling xdebug altogether, my PW installs where back to normal, snappy performance.

Because i don't use xdebug for debugging or profiling i'm fine with totally disabling it. This might be a tip for people experiencing bad performance in relation to xdebug.

What i do find surprising is that with the above settings no actual debugging/profiling is enabled. The only thing xdebug needs to do is collect info for it's stack trace. Would this really cause such slowdowns?

  • Like 4
Link to comment
Share on other sites

  • 1 year later...

Thank you for your post, I had the same issue. There was a noticeable delay, especially when loading an edit template page. I switched xdebug off and the waiting time dropped from ~10s to ~1s. I don't know why xdebug would cause such a big delay.

Link to comment
Share on other sites

Xdebug is not really known for being a performant analysis tool and processwire does sometimes generate quite deeply nested function stacks, which xdebug will fully log. Also wamp isn't really the environment for super performant php anyway. 

  • Like 1
Link to comment
Share on other sites

Wow! Thank you so much. I noticed from time to time that the "backend"/admin area is responding faster on the server as on my local machine. But I had no real idea what causes this. In that time I deactivated Xdebug by disabling some parts in the php.ini. Now I deinstalled Xdebug completely and BÄM™ the "backend" loads much more faster (instead of some seconds to below one second). So it's seems to be a difference between disabling the relevant parts in the php.ini or deinstalling it completely. I found an interesting article discussing this issue. 

  • Like 1
Link to comment
Share on other sites

Such ready made packages will probably always be outperformed by a server, which does rarely more than serving webpages, whereas your laptop is running the whole OS and other programms at the same time. You could try using a vm with something like ubuntu and see if it's faster. I've read a few days ago from sass compilation speed up tips and the author did report that a virtual ubuntu was indeed faster than the hosting mac os computer.

  • Like 1
Link to comment
Share on other sites

  • 2 years later...

Any news on this? Same issues here :(

Edit: Just realized that the loading speed is OK when I have "listen for xdebug" in vscode ENABLED (sic!). When I switch it off, PW get's really bad load times. Can anyone confirm this?

Link to comment
Share on other sites

3 hours ago, bernhard said:

Any news on this? Same issues here :(

Edit: Just realized that the loading speed is OK when I have "listen for xdebug" in vscode ENABLED (sic!). When I switch it off, PW get's really bad load times. Can anyone confirm this?

xdebug has always been slow (all over Google). 

Some things you can do

  1. Disable xdebug Profiler
  2. Disable xdebug Profiler enable trigger
  3. Disable xdebug auto trace
  4. Disable xdebug auto start (if you can)

Helpful hints

http://www.devinzuczek.com/anything-at-all/i-have-xdebug-and-php-is-slow/

  • Like 5
Link to comment
Share on other sites

On 16/01/2016 at 3:53 AM, BitPoet said:

I've recently switched to IIS for development

Hi @BitPoet, if you've got a spare moment do you mind sharing what you've done? I am quite intrigued.

(Perhaps in a separate thread and not hijack this one)

When you say it's really fast, I assume you don't mean XDebug but some other methodology/tools for debugging.

  • Like 2
Link to comment
Share on other sites

2 minutes ago, bernhard said:

Via laragon

<unrelated>

I need to try laragon again. Last time I did, it didn't work for me or I didn't want to exclusively work on PHP 7.x. I still need to support PHP 5.3 + for some of my modules and laragon did not seem to support that?

</unrelated>

  • Like 1
Link to comment
Share on other sites

1 minute ago, kongondo said:

<unrelated>

I need to try laragon again. Last time I did, it didn't work for me or I didn't want to exclusively work on PHP 7.x. I still need to support PHP 5.3 + for some of my modules and laragon did not seem to support that?

</unrelated>

You really should!! Just make sure port 80 is not blocked by any other program ( https://forum.laragon.org/topic/929/no-port-80-in-use-check )

It's incredibly easy to switch php versions and different php settings (like I showed with xdebug). You can even use it as portable version on a usb drive (I think that version is limited to one php version, though). But moving your sites is as simple as copying the related "www" and "data" folders to another instance of laragon.

https://medium.com/@oluwaseye/add-different-php-versions-to-your-laragon-installation-d2526db5c5f1

It's also the fastest setup I've had so far (tried xampp and vagrant).

  • Like 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...