Revisiting Docker for Mac's performance with NFS volumes

Can you share native Linux performance timings for full transparency? If nothing else such details could new developers better gauge what development platform they choose to better maximize their productivity.

The gist there restarts Docker. Did you?

Hi, this should also work with Catalina right?

Sorry I didn't read that you used catalina.
I followed the steps but when I try to connect to my web the browser I'm having the error ERR_CONNECTION_REFUSED

A couple of years back I spent so much time dealing with all of this :(

I finally gave up to the idea of having Docker to run natively on macOS. I repurposed a Mac Mini as a headless Linux box (running Ubuntu Server) and installed Docker there. I still use NFS to share codebases as necessary from my main workstation, and use native docker and docker-compose clients to interact with the remote docker server, which gives me the best of both worlds (not without a few quirks).

You should note that docker-sync is very unstable, stops synching files for "no reason" and you don't even know it. If you are using big drupal projects on day to day basis, it is hell to work with that.

Hi Jeff. After following the steps, I still get

I know you don't have time to understand the intricacies of my local setup might contain, but could you let me know if you have any debugging techniques that might help determine what is happening?

Thanks

Thank you for this! I tried it and I'm experiencing some weird issues. Im using a Docker setup in Mojave, Apache, PHP-FPM setup. All aggregations and opcache are disabled. All other files are updating correctly and fast but my CSS and JS changes aren't working or updating. Any ideas on this?

Thank you very much.

I've been struggling with docker performances but I couldn't find a comprehensive explanation (or, rather, how-to) on how to effectively use nfs in the middle of several projects that didn't leave me much time to think about it.

Thanks to you I've been able to understand (more or less) and quickly change my way of sharing folders and the very poor performances on some big applications now behave decently, and that is a huge relief.

Thanks you very much

Hey, thanks for taking the time to test that!

Upon reading your article I've actually tried it and I found out this approach has one serious problem - permissions. In my setup I need a predictable UID and it's not possible to squash the permissions on the mount side. My superficial investigation indicates that it's probably because docker is actually mounting the volume in overlayfs. Docker for Mac uses ext4 for its persistent file system which should support the perms squash, if only it was easy to change the mountpoint. Seems it would require plug-ins which are not that straightforward to set up a Mac. I need simplicity because the setup will be used by tens of people daily. My experience dictates that anything that could go wrong will go wrong countless times requiring lots of support time. I'm not giving up yet though.

Really interesting write-up, and some solid testing!

I've worked on a Drupal 8 site using Docker on macOS for about two years now. Our team has always struggled with the volume mounts setup & performance, so was excited to test out your NFS solution.

Unfortunately I haven't seen the same improvements in my own benchmarks. The tests I used are a bit different, but represent some of the slowest operations that we do on a daily basis. Particularly nuking & reinstalling all of our dependencies, although extreme, is something we end up doing a lot of, as we switch between branches with various module & core versions. NFS is a bit faster for some operations but a bit slower for others.

Here are my test results. (all tests run a few times, times averaged)

1. composer install with a completely empty vendor directory, which will install Drupal core & all of our contrib modules:

• root dir mounted with delegated: 5 min 01 sec
• root dir mounted with NFS: 4 min 18 sec

2. yarn install with a completely empty node_modules directory:

• root dir mounted with delegated: 1 min 52 sec
• root dir mounted with NFS: 2 min 24 sec (!!)

3. drush cr

• root dir mounted with delegated: 16.564 sec
• root dir mounted with NFS: 12.859 sec

4. Loading the home page, uncached

• root dir mounted with delegated: 770 msec
• root dir mounted with NFS: 1.137 sec (!!)

I compared the NFS mount to a default delegated mount so that I was testing in a similar way to how you were, and because a delegated mount is a pretty standard way to get a project set up.

But that's actually not what we've been working with for the past few months.

Our current setup involves creating container-specific volumes for the subdirectories that contain thousands of files, like so:

volumes:
  node_modules_data:
  vendor_data:
  web_core_data:
  web_modules_contrib_data:

[services ...]:
  volumes:
    - .:/app:delegated
    - web_core_data:/app/web/core
    - web_modules_contrib_data:/app/web/modules/contrib
    - vendor_data:/app/vendor
    - node_modules_data:/app/node_modules

The obvious downside is that we're explicitly NOT syncing these folders between the container and the host. It turns out that that doesn't really matter. All of that code runs on the container, and we're not likely to be modifying the internals of Drupal core or our composer dependencies on a daily basis.

And this approach has a few other downsides:

• To get IDE autocomplete/tooling working, we need to run composer install and yarn install on the host as well as the container. Otherwise the host's folders will be empty or out of date.
• Composer from inside the container isn't able to delete web/core if we're upgrading/downgrading core, because it's a volume mount. The workaround is to rm -rf web/core/* -- then it won't try and delete the folder.
• The most frustrating one: Docker has a bug, maybe, where something just goes wrong with these volumes sometimes. In the middle of writing some code, it will decide to revert the entire vendor folder back to some earlier revision, for example. I suspect this is because we're mounting folders over the top of each other - first everything in the current directory, which includes e.g. vendor, and then trying to overwrite vendor with a different Docker volume. I haven't seen documentation for this approach, so I suspect that it works by chance and its behaviour is not strictly defined. When this happens, we can nuke & reinstall our dependencies to get things working again, but performance slows back down to the level as if none of our special subdirectories had their own volumes.

So far we've stuck with this solution despite its flaws, because the performance is great! It's the closest we've been able to get to native performance:

composer install in 52.785 sec, yarn install in 43.011 sec, drush cr in 6.525 sec, and uncached home page loads in 611 msec.

But it still just feels... a bit dodgy. If only it all just worked, right?! 🤷‍♂️

Thanks for all the effort into this post! appreciate it :)

Thanks very much for this, it still works fine with macOS Big Sur and for my particular task at the moment (lots of write operations of small files) it speeds things up by about 30-40% compared to a regular mounted volume.

The only thing I needed to modify was the user ID for the NFS exports file. Mine happens to be 502, rather than 501 (because the account I'm using was the second one to be created on the machine).