Incredibly slow cache:clear of symfony in dev environment

Question

I am facing problem from last few months that in my local environment the command cache:clear is incredibly slow. Many times it takes more than a minute. I tried it with both XAMPP and WAMP but It didn't help. I tried to solve by removing different services and bundles but situation remains same.

At the end I found the problem is directly proportionate to the number of Twig files I have in my Resources/Views Folder. I even created a new symfony project with standard command

composer create-project symfony/framework-standard-edition test-performance-project "2.7.*"

and created a simple standard controller and twig file to check my hypothesis. The more twig files I added in Resources/Views Folder, the slower the cache:clear command was (More or less proportional). Is there a way to prevent this because in our project we have high number of twig files in our Resources folder.

I am using

Windows 10 PHP 7.0.15 Symfony 2.7.23 Twig 1.31.0

Any help will be highly appreciated :)

Answer 1

I had similar issue with xdebug enabled in my cli environment. Twig parsing does a lot of iterations over template files so xdebug has a huge impact on twig cache generation performance.

Try to comment out this line in your php cli configuration:

;zend_extension=xdebug.so

Answer 2

Things I did to improve performance on windows 10, while keeping xdebug on.

enabled opcache

disabled xdebug.remote_autostart

added x-debug helper extension

Hint: if you have xdebug extension with remote_autostart 1, you should keep listener in your IDE always ON, even if you don't have any breakpoints, otherwise everything will run extremely slow (see case 6).

Some tests using a small symfony 4.2 project, in dev mode, time is DomContentLoaded taken from Chrome:

1. xdebug ON, remote_autostart 0, listener in IDE ON, debug disabled for chrome extension:
   • no cache: 9.5 seconds
   • after caches: 580-620ms
2. xdebug ON, remote_autostart 0, listener in IDE ON, debug enabled for chrome extension:
   • no cache: 16.35 seconds
   • after caches: 950ms-1s
3. xdebug ON, remote_autostart 0, listener in IDE OFF, debug disabled for chrome extension:
   • no cache: 9.02 seconds
   • after caches: 565-650ms
4. xdebug ON, remote_autostart 0, listener in IDE OFF, debug enabled for chrome extension:
   • no cache: 13.99 seconds
   • after caches: 5.54s
5. xdebug ON, remote_autostart 1, listener in IDE ON:
   • no cache: 14.92 seconds
   • after caches: 1.02s
6. xdebug ON, remote_autostart 1, listener in IDE OFF:
   • no cache: 14.92 seconds
   • after caches: 5.69s
7. xdebug OFF:
   • no cache: 6.66 seconds
   • after caches: 483-525ms

I use case 1 usually and when I need to debug I switch to case 2. Cases 3, 4, 5, 6 are relevant for people who might not be aware of implications of IDE listener and debug cookie.

UPDATE

I tested the same project with Windows Subsystem for Linux (WSL) enabled and got some improvements. load times when no caches were something like:

• 6.5 seconds with xdebug enabled but listener off
• 9.5 seconds with xdebug enabled and listener ON
• 2.5 seconds!!! with xdebug disabled

overall WSL improved everything, reducing load time by 50%.

PS: for WSL to work properly you will have to disable Windows Defender Real Time protection, otherwise everything will go 2x slower than without WSL. Maybe there are some options to keep Real Time protection on and exclude WSL, but I don't know at this point.

Answer 3

What did wonders for my cache:clear speed was turning off the profiler with xdebug.profiler_enable = off.

I was using WAMP, on Windows, with PHP 7.1 and 7.2.

With WAMP (but not only with it) the local webhost and your console may not be using the same php.ini file. If you possibly inspect the phpinfo() output in the browser, you may find that the profiler is turned off. But, when you run a cache:clear in the console, the console may not be using the same php.ini file - as it was the case with me.

The php.ini really used from the console had the profiler running, which was causing PHP to create many GBs of cachegrind files, all in the background, hidden from me. I only noticed it when I inspected the Resource Manager's HDD usage, while the cache:clear was happening.

When profiler was turned finally off, the cache:clear was at least 5 times faster.

Answer 4

A symfony core developer asked me that he always do rm -fr var/cache/* so I always do this before running my app.

Also in config_dev.yml make template caching false

twig:
    cache:false