Symfony2 application very slow in VirtualBox

2019-03-29 04:49发布

问题:

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

Performance is very bad. The following are webgrind outputs for the native vbox filesystem and a samba mount with cifs:

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

Isn't the output of all three of these functions cached in the stat cache? Why are they taking so long?

I'd really appreciate any help I can get!

Edit: To clarify, production performance is fine. On our (proper, non-virtual) staging server the PHP code executes in ~60ms max in production settings and somewhere between 100-200ms in dev mode.

I need help figuring out why VirtualBox is 100x slower in dev & prod mode.

I just checked, production settings yield ~5sec execution. Still unusable, plus it's awkward to develop with.

回答1:

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

Your profiling indicates that file system operations are the bottleneck.

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



回答2:

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

I will make a small resume of it. You should not measure performance of your application based solely on the app_dev.php front controller. This controller has been created to be used for development only. In development, you make lots of changes to configuration files, twig templates, assets, etc. Symfony will check hundred of files for modifications and reload a lot of previously cached stuff if necessary hence the high number of calls to filemtime, file_exists and is_readable. All this calls are bypassed in production mode because Symfony expect everything in the cache to be up-to-date. So, almost everything possible is cached in production mode and used right ahead without Symfony checking if the file has been modified or not. This gives a huge performance boost because reloading a single files in development can take a lot of times to parse it, check dependencies on it, recache everything depending on this files and so on.

If you'are benchmarking your application, benchmark it as if it was in production mode. At least, if you can't have all the hardware setup as you expect it in production, do the following steps. Clear your cache for production mode and use app.php instead of app_dev.php. Also, check the section on performance that can be found on symfony.com in the documentation. Here the console calls to clear and warmup your cache in production environment. I think cache:clear will also warmup 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



回答3:

Just to tie this up:

In the end I set up a samba share on the guest OS, bound it to a second network adapter (host-only, like in this guide) and mounted that as a network drive in the host OS.

A little hacky, but execution times are down to 100-500ms from 5-13sec in dev mode with profiling.



回答4:

In addition to what Matt said I recommend you to compile twig extension and use it as php module. It will generate templates faster. But still the most important is to do any benchmarks running your app in prod environment, but not in dev or test. Make sure you don't load xdebug module in production, because it will slow down your benchmarks as well.

I don't know your exact settings, but most-likely you will have better results if you install proper reverse proxy (aka Varnish) instead of AppCache to make as little requests to app itself as possible.



回答5:

Had the same issue, fixed it by setting up a rsync cron that keeps the code on the VM and the host in sync.

Apparently Virtualbox shared folders are pretty slow when it comes to file reading/writing :/

Blogged about my solution in detail if you are interested