xdebug cause slowlyness as well in the www.conf FPM pool

[MatteoOreficeIT]

We would expect that xdebug would be disabled in the www.conf ( in the prod env ), but it degrades surprisingly the overall performances , our ajax wordpress call are delayed for 600-700ms above the 300ms average length with xdebug uninstalled

after search on internet the only way for totally disabling xdebug on prod env is comment the line

zend_extension=/usr/lib/php5/20121212/xdebug.so

in /etc/php5/fpm/conf.d/20-xdebug.ini

look at http://www.frankmayer.me/blog/item/12-xdebug-disabling-vs-not-loading-it-at-all

Is it enabled by default and is it only in v3 or also in v2?

[MatteoOreficeIT]

we have

quasimodo:~# ee -v
EasyEngine v3.0.4
Copyright (c) 2015 rtCamp Solutions Pvt. Ltd.

it is right have it enabled during development but , after we develop our customer apps and we finish debugging them we choose to disable it.

The problem is "it cannot be simply disabled tuning the pool conf file, but we need to unload from php-fpm on the service start phase" because it make all the http requests slow

it is important to know. it seems there are few solutions

http://serverfault.com/questions/481960/is-it-possible-to-set-up-php-fpm-with-different-pool-options-xdebug-enabled-x

[rahul286]

I am looking into this.

Theoretically, loading extra module should increase PHP's memory footprint only. It shouldn't have anything to do with response time (apart from very small time that goes in allocating extra memory).

[MatteoOreficeIT]

yes it is, we have a linode with a stock debian 7 with a standard easyengine install and wordpress site, 1 site.

we investigated the problem because we had wordpress ajax action wp_ajax_nopriv_ & wp_ajax_ very slow, a stupid handler which echo "hello world" took 600ms .

after unloading xdebug it took the 250-300 ms, which could be the wordpress overhead on this system and network combination

[rahul286]

I am not able to find a workaround yet to prevent xdebug loading in production (www) pool. Also, I disabled manually on few sites and difference is very very small.

Still, I believe xdebug loading should be prevented in production. So I am still looking for a workaround where we can have xdebug in debug pool and not load it in www pool.

[rahul286]

Workarounds

Solution-1

Try: http://stackoverflow.com/a/20724365/156336

Command is php5-fpm.

Problem: we may not be able to use service php5-fpm start|stop|restart

Solution-2

1. Remove debug pool.
2. Move xdebug config to /etc/php5/mods-available/xdebug.ini and keep it commented.
3. ee debug --php will comment/uncomment lines and restart php5-fpm

Problem:

1. All sites will run in debug mode or no-debug mode or current-mode (if we maintain 2 pools).
2. Might create bigger problem in shared hosting where every user supposed to get different pools.

[rahul286]

@Rippler xdebug is disabled by default but loaded always.

Can you try commenting only line present in /etc/php5/mods-available/xdebug.ini and restart fpm service php5-fpm restart?

If you find any performance difference please report. I need more data points.

Loading xdebug shouldn't make much difference, but if its making big difference, we will definitely do something about it right away.

[gau1991]

We fixed this issue in latest EE 3.0.9. Now xdebug is enabled only during EasyEngine debug command.

[rahul286]

Note

We haven't thought about debugging in shared hosting env for now. I guess it will take us more than 6 months before we can think of start any work on shared hosting feature. As technology keeps changing rapidly, we will revisit this thread at that time to see if we get any new kind of workaround.