Symfony2 application is very slow in VirtualBox

Question

I am running a virtual copy of Debian on VirtualBox to develop a larger PHP application in the nginx / php5-fpm / MySQL stack. Development takes place in the host OS (Windows 7 x64), the code is mounted as a shared folder in the guest OS.

Performance is very poor. The following are the outputs of webgrind for the native vbox and mount samba file systems with cifs:

In either case, filemtime , file_exists and is_readable take several seconds to complete. CPU utilization is very high, memory usage seems normal.

Are all three of these functions output to the cache cache? Why are they taking so long?

I would really appreciate any help I can get!

Edit: To clarify, performance performance is excellent. On our (correct, non-virtual) intermediate server, the PHP code is executed at a size of ~ 60 ms in production settings and somewhere between 100-200 ms in dev mode.

I need help figuring out why VirtualBox is 100 times slower in dev and prod mode.

I just checked production settings give ~ 5 seconds of execution. Still unusable, plus inconvenient to develop with that.

Answer 1

Use file sharing nfs. Samba and the vbox share can be very slow.

Your profiling indicates that the file system is a bottleneck.

Read this blog post http://clock.co.uk/tech-blogs/virtualbox-404-shared-folder-update for a deeper understanding

Answer 2

I recently answered a similar question. You can find my previous answer here .

I will make a short summary. You should not measure the performance of your application based solely on the app_dev.php front controller. This controller is designed for development use only. In development, you make many changes to configuration files, branch templates, assets, etc. Symfony will check hundreds of files for modifications and reload a lot of previously cached materials, if necessary, therefore a large number of calls to filemtime , file_exists and is_readable . All these calls are bypassed in production mode because Symfony expects everything in the cache to be updated. Thus, almost everything possible is cached in production mode and is used straight forward without Symfony checking if the file has been modified or not. This gives a huge performance boost, because reloading individual files in development can take a long time to parse it, check dependencies on it, rewrite everything depending on these files, etc.

If you are comparing your application, compare it as if it were in production mode. At the very least, if you cannot install all of the hardware as you expect in the production process, follow these steps. Clear the cache for production mode and use app.php instead of app_dev.php . Also check out the performance section, which can be found on symfony.com in the documentation. Here the console calls to clean and warm up your cache in a working environment. I think cache:clear also heats the cache, but since I'm not 100% sure, I prefer to make both calls:

 php app/console cache:clear --env=prod --no-debug php app/console cache:warmup --env=prod --no-debug 

Hope this helps.

Regards, Matt

Answer 3

Just to relate this:

In the end, I installed the samba share on the guest OS, connected it to the second network adapter ( only for the host, as in this guide ) and mounted it as a network drive in the host OS.

A bit hacked, but the execution time is reduced to 100-500 ms from 5-13 seconds in dev mode with profiling.

Answer 4

In addition to what Matt said, I recommend that you compile the twig extension and use it as a php module. It will generate patterns faster. But still, the most important thing is to do some tests that run your application in the prod environment, but not in dev or test. Make sure you are not loading the xdebug module into production, because it will also slow down your tests.

I don’t know your exact settings, but most likely you will have better results if you install the correct reverse proxy (aka Varnish) instead of AppCache to make as few requests as possible to the application itself.

Answer 5

Had the same problem, fixed it by installing rsync cron, which synchronizes the code on the virtual machine and the host.

Virtualbox public folders seem to be pretty slow when it comes to reading / writing files: /

Describe my solution in detail if you are interested