Optimize Drupal performance for Docker on Mac with bundled Mutagen file caching in 2020
Mutagen file volume caching is now live in Docker Desktop for Mac Edge channel. This means better performance for local Drupal development using Docker containers.
https://docs.docker.com/docker-for-mac/mutagen-caching/
Docker Desktop (Edge): https://docs.docker.com/docker-for-mac/edge-release-notes/
Drupal performance on Docker Desktop Mac edition on any large scale project is abysmal. Drupal 8, symfony and composer added to the file system bloat. The problem is the performance of the oxfs / shared host volumes from mac to the docker VM rather than an execution bottleneck.
Requirements:
- Mac OSX
- Docker Desktop for Mac (Edge Build)
- Linux Docker Containers
There have been work arounds but nothing that was easy to onboard other developers on your team and it required a third party tool or fiddling with NFS which has another set of problems usually with permissions.
The big promise with using Docker on mac is mirroring production environments either hosted docker or building using the same OS releases without running boot camp or the care and feeding of managing your own VMs.
You have to download Docker Desktop (Edge build) but after you have that setup is a breeze: Open docker desktop settings from the whale in the mac menu bar. Select preferences cog in the blue bar. Select resources and add your drupal project directory and click the cached radio toggle.
Initial cache sync will take a long time depending (10s of minutes) on how large your project directory is. My tip is select the most specific directory possible. Don’t cache /Users, ~/ (current user directory) or high level. In our case with Drupal this happens to be the directory holding root drupal project (not just /web if you are using the composer setup for D8)
There are caveats of course it is a two way sync but the host will always win if there are conflicts. If you are running in git this is probably the way you want it to work anyways… at least I do.
The one feature I would love would be an additional settings cog where I could enter in excluded directories or a .*ignore file. That being said this is awesome.
Disabling it is a breeze and doesn’t require any restructuring of volumes in your docker-compose.yml files so this is a low risk test. If you use Drupal & Docker this a no brainer and you have probably been waiting for this.
This also applies to other PHP projects using Docker Desktop on Mac such as Symfony. As well as other web projects that have large number of variable files… *erhem *NodeJs/NPM *erhem* as well as large SCSS/SASS, react and webpack projects.
Also other notes to help with local performance which may not apply to prod. Performance tuning can really getting into SysAdmin/DevOps skillset but it is valuable for any Full Stack Engineer or Web Developer to learn about their stacks:
- Run the latest versions of PHP possible 7.3/7.4
- Use a NGINX, PHP-FPM, MariaDB/MySQL (LNMP) stack vs traditional LAMP stack. See the Wodby local stack https://github.com/wodby/docker4drupal
- Give docker enough memory 2–4GB.
- Set your PHP memory limit higher to support a lower number of requests but better performance.
- Provide Docker with enough processors 2–4.
- Reduce the number of files in your Drupal project when possible move hosted files outside the project or don’t host them as a local share but rather as a shared docker volume (Warning) that means they may go away when the container does.
- Run Memcache/Redis with Drupal extensions, but this comes with downside of needing to tune your cache for local development… which maybe another blog post.
- Native MySql / MariaDB will be faster than containerized so this is always an option.
- If using Docker Compose/Swarm/Kubernetes add some additional replica containers.
These are just recommendations I have found may help with large Drupal projects with a high number of installed contrib as well as custom modules and composer vendor libraries. Each project must be evaluated on it’s architecture and some of these things may reduce performance so each change should be made in isolation, tested, measured, compared and determined if it is right for your local development environment.
As always caveat emptor!
