Spryker VM super slow when xdebug is running


#1

hey guys,

right now we develop a b2c shop with spryker. But the virtual machine becomes really really slow when we start the debugger no matter if we start the demo shop or our own spryker system.

We don’t work with slow hardware. We’re using Macbook Pro’s (i7 2,9 GHz, 16 GB RAM).
We could accept a slow vm but the real problem is that the vm is so super slow that we get timeouts even before we reach our breakpoints as soon as we activate our debugger in phpstorm.

If someone has a solution for this problem, we would be very happy if he or she could share it with us.


#2

Hi Christian,

could you please clarify the version of devvm you are using and if opcache is enabled or disabled?

Best regards,
Valerii


#3

Also please check if you can connect to the Storm on your host. It can be that your debugger can’t connect to the IDE.

https://xdebug.org/docs/remote
Check remote host and port please.

Best regards,
Valerii


#4

Can you please make sure that you always add the “-o” option to composer install?

composer install -o

By doing that you create optimised autoloader files. What it means: it saves a lot of filesystem calls, which check if PHP files exist. Those calls are going thru (virtualized) network, which adds latency to each one. As you have opcache disabled, you are exposed directly to the poor performance of PHP using files from network share. Hopefully using optimised autoloader will make things faster for you.

Best,
Marek Obuchowicz
KoreKontro.eu - Spryker hosting platform


#5

Hi Valerii,

thanks for your quick answer.

My OPcache: Zend OPcache v7.2.14-1+0~20190113100742.14+stretch~1.gbpd83c69
VirtualBox: 5.2.22 r126460 (Qt5.6.3)
Vagrant: 2.1.4


#6

Hi Marek,

I did the composer install again with -o. But still it is too slow.


#7

I can confirm that running spryker in some situations like checkout process is very slow with enabled debugging. It takes up to one minute from one checkout process step to another.
Clicking the “Stop listening for debug connections” button is dramatically speeding up the whole thing.
But i never ran into a timeout …
My trick was to “Start listening for debug connections” first when i am really on the step i want to debug. The other time, the debug listener in PHPStorm is turned off.


#8

Hi Jim,

yeah I also only activate my debugger when I really need it.

Like now… I really need it but no chance with the timeout.


#9

I have another clue …

Can you also check, that your connection settings is accepting more than one debug connection (as described in the docs)?

Sometimes I noticed a timeout problem whenever i started a debug session over Yves frontend. The connection is blocked by another request in the background somehow and your browser is waiting to get this released … it was like a deadlock.

Best regards


#10

I Tried this right now. It was set on 2 connections. I even changed it to 5 and 10. But with not difference.


#11

It sounds a bit similar to the problem i got few months ago …

It just happens when i tried to debug zed but with starting a debug session in frontend …
The problem disappeared as i tried to let the browser start the debug session (not by using the “debug zed/yes” button from IntelliJ as described in the docs).

Have you maybe setup auto_reconnect to your xdebug.ini? This could also lead to different problems.

I can remember that this was very annoying at this time but i never faced the problem again.

Can you ensure, that the problem is definitely a “slow request” problem? I guess that it doesn’t matter how slow it is cause its probably in a deadlock … so setting up the timeout time to a much higher value should clear this.

Also: Can you show us your xdebug.log and exactly from where the session was started?


#12

I set the fastcgi_read_timeout to 3600. Now i receive this:

YVES Exception
Spryker\Shared\ZedRequest\Client\Exception\RequestException - Failed to complete request with server authority http://zed.de.segmueller-shop-suite.local. Configured with (SSL Disabled) zed.de.segmueller-shop-suite.local:80 in /data/shop/development/current/config/Shared/config_default.php. Error: Stacktrace:
in /data/shop/development/current/vendor/spryker/zed-request/src/Spryker/Shared/ZedRequest/Client/AbstractHttpClient.php (224)

Url:/cart

Trace:

#0 /data/shop/development/current/vendor/spryker/zed-request/src/Spryker/Shared/ZedRequest/Client/AbstractZedClient.php(80): Spryker\Shared\ZedRequest\Client\AbstractHttpClient->request('/cart/gateway/v...', Object(Generated\Shared\Transfer\QuoteTransfer), Array, NULL)
#1 /data/shop/development/current/vendor/spryker/zed-request/src/Spryker/Client/ZedRequest/ZedRequestClient.php(50): Spryker\Shared\ZedRequest\Client\AbstractZedClient->call('/cart/gateway/v...', Object(Generated\Shared\Transfer\QuoteTransfer), NULL)
#2 /data/shop/development/current/vendor/spryker/cart/src/Spryker/Client/Cart/Zed/CartStub.php(91): Spryker\Client\ZedRequest\ZedRequestClient->call('/cart/gateway/v...', Object(Generated\Shared\Transfer\QuoteTransfer))
#3 /data/shop/development/current/vendor/spryker/cart/src/Spryker/Client/Cart/Plugin/SessionQuoteStorageStrategyPlugin.php(312): Spryker\Client\Cart\Zed\CartStub->validateQuote(Object(Generated\Shared\Transfer\QuoteTransfer))
#4 /data/shop/development/current/vendor/spryker/cart/src/Spryker/Client/Cart/CartClient.php(229): Spryker\Client\Cart\Plugin\SessionQuoteStorageStrategyPlugin->validateQuote()
#5 /data/shop/development/current/vendor/spryker-shop/cart-page/src/SprykerShop/Yves/CartPage/Dependency/Client/CartPageToCartClientBridge.php(129): Spryker\Client\Cart\CartClient->validateQuote()
#6 /data/shop/development/current/vendor/spryker-shop/cart-page/src/SprykerShop/Yves/CartPage/Controller/CartController.php(56): SprykerShop\Yves\CartPage\Dependency\Client\CartPageToCartClientBridge->validateQuote()
#7 /data/shop/development/current/vendor/spryker-shop/cart-page/src/SprykerShop/Yves/CartPage/Controller/CartController.php(38): SprykerShop\Yves\CartPage\Controller\CartController->executeIndexAction(Array)
#8 [internal function]: SprykerShop\Yves\CartPage\Controller\CartController->indexAction(Array)
#9 /data/shop/development/current/vendor/symfony/http-kernel/HttpKernel.php(144): call_user_func_array(Array, Array)
#10 /data/shop/development/current/vendor/symfony/http-kernel/HttpKernel.php(64): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#11 /data/shop/development/current/vendor/silex/silex/src/Silex/Application.php(586): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /data/shop/development/current/vendor/silex/silex/src/Silex/Application.php(563): Silex\Application->handle(Object(Symfony\Component\HttpFoundation\Request))
#13 /data/shop/development/current/public/Yves/index.php(22): Silex\Application->run()
#14 {main}

But I really don’t know what to do with it.


#13

Okay, sounds also like timeout from the client side. As i said … i guess the corresponding zed code stucks somewhere in the debugging process, maybe because of a misconfigured behavior like auto_reconnect or something else. So, please provide the xdebug.ini and the xdebug.log …


#14

It looks to me like you are making an Yves request, then internally Yves make a call to Zed, and this Zed request never completes. Maybe it’s stuck on breakpoint somewhere in Zed? Can you make sure you have no breakpoints defined?

Best,
Marek Obuchowicz
KoreKontro.eu - Spryker hosting platform


#15

xdebug.ini:
zend_extension=xdebug.so
xdebug.remote_enable=1
xdebug.remote_host=10.10.0.1
xdebug.remote_autostart=0
xdebug.remote_port=9321
xdebug.max_nesting_level=1000
xdebug.remote_log=/var/log/xdebug.log

xdebug.log

Log opened at 2019-01-31 10:09:04

I: Connecting to configured address/port: 10.10.0.1:9321.

W: Creating socket for '10.10.0.1:9321', connect: Network is unreachable.

E: Could not connect to client. :-(

Log closed at 2019-01-31 10:09:04

Log opened at 2019-01-31 10:09:04

I: Connecting to configured address/port: 10.10.0.1:9321.

W: Creating socket for '10.10.0.1:9321', connect: Network is unreachable.

E: Could not connect to client. :-(

Log closed at 2019-01-31 10:09:04

But since then I had no more new log entries and i tried this out many times after 10:09 am


#16

I made sure that all breakpoints are deleted but still same problem.


#17

Can you ping the 10.10.0.1 from the inside of your vagrant vm? If yes, is the port 9321 the one you set up also in your IntelliJ/PHPStorm config? The error message clearly says that it can get no connection to your host.

Also if you got no more log entries it may be that xdebug isn’t activated anymore (check with php -i command if xdebug is still enabled)

If xdebug is still in your config, make sure, you started a xdebug session. To start a session from browser you may need something like a debug extension for your browser (like xdebug helper for chrome) and make sure, that you enable debugging for the current tab (i forgot this several times, but debug will not work without this step).

At least the log entry should appear now if everything is correct.


#18

I can ping 10.10.0.1 from inside. The port 9321 is set in phpstorm too.

xdebug is enabled

xdebug

xdebug support => enabled
Version => 2.6.1
IDE Key => vagrant

I also enabled xdebug helper in the shop tab :slight_smile:

Could the IDE Key be the problem?


#19

Imo, the IDE key isn’t relevant for establishing connection to the host. But you should also set it to the one you expect in your IDE.

Are there log entries again?

Starting the session from the browser should produce log entries now.

At the moment you click on “Start listening for php xdebug connections” in PHPStorm the port 9321 is open for 10.10.0.1 and at least a connection (logged in xdebug.log) should be established even if there is no reaction from the IDE in cause of a missing/not matching IDE key.

Another guess: Make sure you only run one instance of IntelliJ. Running two instances with the same port (9321) listening will end up in a conflict. At least make sure that not both instances are listening to the same port at the same time.