Running the Symfony application on Vagrant without NFS below 100ms

9 December 2014

This post explains how to configure Symfony/Vagrant to get response time below 100 ms. And how to do it without NFS! This is, in my opinion, the best way to run the Windows/Vagrant/Symfony combination.

1. Background

If you try to run the Symfony application within the Vagrant box on Windows you will, most probably, get a page load time of almost 5 or 10 seconds. Which, of course, is unbearable.

This is the starting point:

The task is: how to configure the development machine to minimise the page-load time?

That’s really important for me, as the majority of young developers who I educate use Windows.

2. The solution

My solution is very simple: move vendor/ outside shared project’s folder.

Yes, it’s as simple as that.

To do this, you need to make two simple changes:

Here is the first change you have to introduce in the composer.json file:

//filename: composer.json
{
    ...
    "config": {
        "bin-dir": "bin",
        "vendor-dir": "/home/vagrant/symfony2app/vendor"
    },
    ...
}

And this is the second change:

//filename: app/autoload.php
/**
 * @var ClassLoader $loader
 */
$loader = require '/home/vagrant/symfony2app/vendor/autoload.php';

Now, you have to install dependencies:

$ composer install

And… enjoy!

Even if you don’t apply any other optimisations, you will get a substantial speed-up.

3. Reason

Why does this change lead to such amazing results? Vagrant has a very poor I/O performance of on shared folder. This is a well known feature of virtualized solutions. You can find more details in the post Comparing Filesystem Performance in Virtual Machines.

The analysis and benchmarks of the Vagrant/Symfony application is available in the post entitled Optimizing Symfony applications on Vagrant boxes.

4. Other optimizations

Of course, it is worth your while to implement other well-known solutions. Thanks to the excellent post Speedup Symfony2 on Vagrant boxes you should already know, how to move cache/ and logs/ to other location, /dev/shm, for example. The official documentation contains a cookbook entry that you might also want to take a look at: How to Override Symfony’s default Directory Structure.

Another good starting point for pursuing Symfony optimisation is the post entitled Symfony2 Slow Initialization Time on StackOverflow. There you will find info about changing php.ini settings:

5. The boxed solution - one more trick

If you work with Symfony/Vagrant I have one more trick to share. It is also very simple and leads to substantial time saving. It doesn’t affect page-load time, but it does reduce the time you need to run the:

$ composer install

command. The trick is: cache dependencies in your box.

How do you do it? When you create a boxed solution with:

$ vagrant package --output symfony-box-v1.2.3.box

try to run, just before the above command, the composer:

 $ composer install

Do it in an arbitrary directory and use the composer.json for the latest Symfony Standard, for example.

This trick is important if you start new projects quite often. During my lessons, I start a new project with every group of students once a week. By caching dependencies we save a lot of time (and nerves!).

6. Summary

Here are the tricks, that have made my Windows/Vagrant/Symfony classes viable:

7. Reading list

  1. Mitchell Hashimoto: Comparing Filesystem Performance in Virtual Machines
  2. Erika Heidi: Optimizing Symfony applications on Vagrant boxes
  3. Benjamin Eberlei: Speedup Symfony2 on Vagrant boxes
  4. orourkedd, Dénes Papp Symfony2 Slow Initialization Time
Fork me on GitHub