

The database is stored on a separate Docker volume, and not shared, so it is plenty fast on its own (and doesn't affect the results).

The operation requires loading thousands of code files from the shared volume, writes a number of files back to the filesystem (code, generated templates, and some media assets), and does a decent amount of database work. The first benchmark installs Drupal, using the codebase. Since around 2016, support has been around (albeit barely documented) for NFS volumes in Docker (see Docker local volume driver-specific options).Īs part of my site migration project, I've been testing different local development environments, and as a subset of that testing, I decided to test different volume/sync options for Docker to see what's the fastest-and easiest-to configure and maintain.īefore I drone on any further, here are some benchmarks: Since then, the File system performance improvements issue has been a common place to gripe about the lack of improvements to the underlying osxfs filesystem. It was painfully slow, and the community finally got a cached mode that offered a 20-30x speedup for common disk access patterns around 2017. So, read on.Įver since Docker for Mac was released, shared volume performance has been a major pain point.

September 2020 Update: Alas, Docker for Mac will not be getting built-in Mutagen support at this time. Hopefully that feature makes it to the standard Docker for Mac version soon. July 2020 Update: Docker for Mac may soon offer built-in Mutagen sync via the :delegated sync option, and I did some benchmarking here. But it's actually fairly performant using the barely-documented NFS option! It's acceptable (but still very slow) if you use the cached or delegated option. Tl dr: Docker's default bind mount performance for projects requiring lots of I/O on macOS is abysmal.
