Exploring Ways To Improve Vagrant Performance

Jan 28, 2015Ryan Burnette

As a developer who is frequently switching between projects, Vagrant is one of my favorite tools. It gives me a fast, automated way to create a virtual machine instance that's tailored to the needs of each project. All environmental concerns are isolated in that instance. This makes switching between projects painless and eliminates my old pains where tweaking my environment for one project broke my environment for another.

Lately I've been developing a growing Rails app that, as it has grown, has steadily raised the need for better performance. My Vagrant boilerplate had no CPU configuration and stuck with the standard 1 gigabyte of memory for quite a long time. I've had to make some changes and I'll get right into it.

First, let me disclose that everything I've done came from advice in this Stefan Wrobel post about making Vagrant performance not suck. A simple Google search got me there and taking a few tips from the post helped me realize serious gains in performance.

Use Cores + 1/4 Memory

Wrobel has some code in his examples that configures the instance to use all your cores. There's also code that automatically allocates 1/4 of your system memory. Why didn't I think of this? When I'm working with a team on a project that has a Vagrantfile, I've heard the complaint that the memory number is too low or too high. I gave pause before making a change because we all have a different amount of system memory. How much was too much? This eliminates that concern.


If you hit the Vagrant synced folders doc for NFS, the first thing you'll read about is how the default sync option has performance penalties. It's yet another reminder to RTFM.

In Wrobel's post he points out the same thing. It's something I had noticed, but up until now it hadn't bothered me enough to change.

After I started using NFS for synced folders I noticed the biggest performance gain of all. Another interesting point in Wrobel's post are his application benchmarks after switching to NFS.

For me, I've been doing a lot of my editing in Vim over the Vagrant SSH connection in order to reap benefits from Rails-integrated Vim plugins. This was what caused the lack of performance to really push me to find a solution.

Stuff I'm Still Doing My Way

Wrobel also advises building your base box and storing it so there's no provisioning step. I get the basis for the advice, but I'm going to keep letting my instances provision themselves when I build them. It's a great excuse to get up from the computer for a walk around. Studies show that sitting for too long can shorten your life span. So it's really a matter of health, right? It's also a great opportunity to get another cup of coffee.

Also, it's a small matter, but I don't like the idea of diverging from the base box. I'm probably not on to anything of real merit here considering that you can use apt-get upgrade to get your box back up-to-speed, but still. I also tend to use faster options for provisioning a development environment, so for my projects we'd only be talking about a savings of a couple minutes during the initial creation.

Also check out my boilerplate Vagrantfile to see all my Vagrant tricks in action at once. Note that I only implemented Wrobel's code as it applies to Mac OS.

Blog Index