Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try NFS or another Docker sync solution for faster performance #22

Closed
geerlingguy opened this issue Mar 11, 2020 · 9 comments
Closed

Try NFS or another Docker sync solution for faster performance #22

geerlingguy opened this issue Mar 11, 2020 · 9 comments

Comments

@geerlingguy
Copy link
Owner

@geerlingguy geerlingguy commented Mar 11, 2020

I tried a bunch of different local environments in #18, and found that Drupal VM was the fastest all-around, but had some inconveniences compared to my current setup.

So now I would like to see if I can get things running (both locally and in CI) using an NFS native mount (see https://www.firehydrant.io/blog/nfs-with-docker-on-macos-catalina/), or using docker-sync or something like that:

@geerlingguy

This comment has been minimized.

Copy link
Owner Author

@geerlingguy geerlingguy commented Mar 11, 2020

I first edited my NFS exports file:

sudo nano /etc/exports

I added the following line:

/System/Volumes/Data -alldirs -mapall=501:20 localhost

(When I saved the file macOS popped a permissions prompt which I had to accept to allow Terminal access to write to this file.)

I also edited my NFS config file:

sudo nano /etc/nfs.conf

I added the following line:

nfs.server.mount.require_resv_port = 0

Then I restarted nfsd:

sudo nfsd restart

Then I added the following to my docker-compose.yml:

---
version: '3'

services:
  drupal:
    [...]
    volumes:
      - 'nfsmount:/var/www/html'

volumes:
  nfs:
    driver: local
    driver_opts:
      type: nfs
      o: addr=host.docker.internal,rw,nolock,hard,nointr,nfsvers=3
      device: ":${PWD}"

NOTE: I initially had o: addr=addr=host.docker... and that blew everything up.

To my docker-compose.yml file.

Note that I have my project in ~/Sites, which is covered under the /System/Volumes/Data umbrella... for older macOS versions you would use /Users instead, and for locations outside of your home directory, you have to grant 'Full Disk Access' in the privacy system preference pane to nfsd.

Some of this info I picked up from this gist and it's comments, especially the comment from egobude about the changes required for Catalina.

@geerlingguy

This comment has been minimized.

Copy link
Owner Author

@geerlingguy geerlingguy commented Mar 11, 2020

The first time I tried this I got:

$ docker-compose up -d  
Creating network "jeffgeerling-com_default" with the default driver
Creating volume "jeffgeerling-com_nfs" with local driver
Creating jeffgeerling-com ... error
Creating drupal-mysql     ... 

ERROR: for jeffgeerling-com  Cannot create container for service drupal: error resolving passed in nfs address: lookup aCreating drupal-mysql     ... done

ERROR: for drupal  Cannot create container for service drupal: error resolving passed in nfs address: lookup addr=host.docker.internal: no such host
ERROR: Encountered errors while bringing up the project.

So I dug through docker/for-mac#2965, and tried a suggestion or two. None worked, so I went ahead and completely reset Docker for Mac to factory defaults. This took a few minutes, but after it was done, I tried again.

@geerlingguy

This comment has been minimized.

Copy link
Owner Author

@geerlingguy geerlingguy commented Mar 11, 2020

nfsd checkexports can be used to check exports.

I'm still not getting anywhere with the above error. Tried docker.for.mac.localhost, as well as 192.168.65.2 (what it resolved to), and that didn't work either.

@geerlingguy

This comment has been minimized.

Copy link
Owner Author

@geerlingguy geerlingguy commented Mar 11, 2020

Got things working, we'll see how this does!

@geerlingguy

This comment has been minimized.

Copy link
Owner Author

@geerlingguy geerlingguy commented Mar 11, 2020

NFS makes for a lot better performance. More than 2x faster in all benchmarks in #18... Going to compare to docker-sync next. Need to figure out if I can get the same docker-compose.yml working in CI...

geerlingguy added a commit that referenced this issue Mar 12, 2020
@geerlingguy

This comment has been minimized.

Copy link
Owner Author

@geerlingguy geerlingguy commented Mar 12, 2020

Commit/branch above is for NFS support. Probably won't pass CI though — yet.

Testing docker-bg-sync now.

@geerlingguy

This comment has been minimized.

Copy link
Owner Author

@geerlingguy geerlingguy commented Mar 12, 2020

With docker-bg-sync, there are a few downsides:

  • You have to use an awkward shared volume (see v3 use here: cweagans/docker-bg-sync#23 (comment)).
  • To be able to watch an entire Drupal installation, you have to give the container privileged access, which is a security risk (I trust @cweagans, but still...)
  • The initial sync can take some time—in addition to the time it takes MySQL to spool up, you have to wait for unison to do an initial sync. Clocked at 4 min 30 sec the first time!
    • CPU was also 150-200% pretty much the entire time it was doing that initial sync.
    • Drupal codebase has something like 32,000 files in it 😳
  • It seems that 2-way sync is a little more difficult, and can be problematic.
  • Also see cweagans/docker-bg-sync#9
@geerlingguy

This comment has been minimized.

Copy link
Owner Author

@geerlingguy geerlingguy commented Mar 12, 2020

Now trying docker-sync. First I installed it on my Mac:

gem install docker-sync

Then I added a docker-sync.yml file next to my docker-compose.yml file:

---
version: "2"
options:
  compose-file-path: 'docker-compose.yml'
  verbose: false
  max_attempt: 5
  project_root: 'pwd'

syncs:
  docker-sync:
    sync_strategy: 'native_osx'
    src: './'
    host_disk_mount_mode: 'cached'

And I set the drupal container volume like so:

volumes:
  - docker-sync:/var/www/html:nocopy

And added volumes to the docker-compose:

volumes:
  docker-sync:
    external: true

It took 2 min 15 sec on the first run to sync everything. Testing performance now.

@geerlingguy

This comment has been minimized.

Copy link
Owner Author

@geerlingguy geerlingguy commented Mar 12, 2020

Performance is on par with bg-sync and NFS... NFS is by far the least intrusive (besides osxfs mounts with :delegated), so I think for now I'm going to stick with that. But I'll push up all the branches, make PRs, then delete the branches, so the work is present in this repo for future reference.

geerlingguy added a commit that referenced this issue Mar 12, 2020
geerlingguy added a commit that referenced this issue Mar 12, 2020
geerlingguy added a commit that referenced this issue Mar 12, 2020
geerlingguy added a commit that referenced this issue Mar 12, 2020
Issue #22: Use NFS for local mount for better performance.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

1 participant
You can’t perform that action at this time.