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

Docker containers file system performance under different scenarios #249

Open
lpeabody opened this Issue Jun 5, 2017 · 36 comments

Comments

Projects
None yet
7 participants
@lpeabody
Copy link

lpeabody commented Jun 5, 2017

Docker for Mac Edge now supports a :cached flag that can be appended to volumes which helps find a significant boost to read performance, see docker/for-mac#77.

What is your recommendation on how to apply this tag to volume mappings? Would you apply it to all of them?

Output of fin config:

fin config output
---------------------
COMPOSE_PROJECT_NAME_SAFE: docksalblt
COMPOSE_FILE:
/Users/les.peabody/.docksal/stacks/volumes-bind.yml
/Users/les.peabody/.docksal/stacks/stack-acquia.yml
/Users/les.peabody/Sites/docksalblt/.docksal/docksal.yml
ENV_FILE:
/Users/les.peabody/Sites/docksalblt/.docksal/docksal.env

PROJECT_ROOT: /Users/les.peabody/Sites/docksalblt
DOCROOT: docroot
VIRTUAL_HOST: docksalblt.docksal
VIRTUAL_HOST_ALIASES: *.docksalblt.docksal
IP: 192.168.64.100
MYSQL: 192.168.64.100:32778

Docker Compose configuration
---------------------
networks: {}
services:
  cli:
    dns:
    - 192.168.64.100
    - ''
    environment:
      HOST_GID: '1106437719'
      HOST_UID: '1729411499'
      XDEBUG_ENABLED: '0'
    hostname: cli
    image: lpeabody/blt-cli
    volumes:
    - host_home:/.home:ro
    - docksal_ssh_agent:/.ssh-agent:ro
    - project_root:/var/www:rw
  db:
    dns:
    - 192.168.64.100
    - ''
    environment:
      MYSQL_DATABASE: default
      MYSQL_PASSWORD: user
      MYSQL_ROOT_PASSWORD: root
      MYSQL_USER: user
    hostname: db
    image: docksal/db:1.0-mysql-5.5
    ports:
    - 3306/tcp
    volumes:
    - project_root:/var/www:ro
  memcached:
    dns:
    - 192.168.64.100
    - ''
    environment:
      MEMCACHED_MEMORY_LIMIT: '128'
    hostname: memcached
    image: memcached
  solr:
    dns:
    - 192.168.64.100
    - ''
    hostname: solr
    image: docksal/solr:1.0-solr4
  varnish:
    depends_on:
      web:
        condition: service_started
    dns:
    - 192.168.64.100
    - ''
    environment:
      VARNISH_BACKEND_HOST: web
    hostname: varnish
    image: docksal/varnish:1.0-varnish4
    labels:
      io.docksal.virtual-host: varnish.docksalblt.docksal
  web:
    depends_on:
      cli:
        condition: service_started
    dns:
    - 192.168.64.100
    - ''
    environment:
      APACHE_DOCUMENTROOT: /var/www/docroot
    hostname: web
    image: docksal/web:1.0-apache2.2
    labels:
      io.docksal.project-root: /Users/les.peabody/Sites/docksalblt
      io.docksal.virtual-host: docksalblt.docksal,*.docksalblt.docksal
    volumes:
    - project_root:/var/www:ro
version: '2.1'
volumes:
  docksal_ssh_agent:
    external: true
  host_home:
    driver: local
    driver_opts:
      device: /Users/les.peabody
      o: bind
      type: none
  project_root:
    driver: local
    driver_opts:
      device: /Users/les.peabody/Sites/docksalblt
      o: bind
      type: none

---------------------

@achekulaev

This comment has been minimized.

Copy link
Member

achekulaev commented Jun 6, 2017

For now I would think it's fin config generate and edit resulting docksal.yml as much as you need.
I guess we might include this option in future as default one, when it's stable.

@lpeabody

This comment has been minimized.

Copy link

lpeabody commented Jun 6, 2017

@achekulaev they are looking at a stable mid-June release, actually, in 17.06. I'll try your recommendation and note performance improvements, if any, here.

@lmakarov

This comment has been minimized.

Copy link
Member

lmakarov commented Jun 6, 2017

@lpeabody you want to add :cached on the project_root volume in cli, like this:

  cli:
    ...  
    volumes:
      # Project root volume
      - project_root:/var/www:rw,cached

I installed the latest edge release of Docker for Mac (Version 17.06.0-rc1-ce-mac13 (18169)) to test this. Either I'm doing something wrong, or there is no difference.

I'm running my standard test with time drush si -y (3 runs) and seeing no changes in the results regardless of the flag value.

Without :cached

real	0m58.845s
real	0m58.577s
real	1m5.246s

With :cached

real	1m6.226s
real	1m7.792s
real	1m1.457s
@lpeabody

This comment has been minimized.

Copy link

lpeabody commented Jun 7, 2017

@lmakarov Confirmed, I see the same results, running at 2m38s and 2m45s for my si command (running a custom installation profile). Definitely something to keep plugging at though. If others are seeing vastly improved results like @geerlingguy does here (docker/for-mac#1592 (comment)) then maybe we're doing something that is a bit of?

One thing he notes is that he wants to be using rw,delegated but sounds like he's replacing rw,delegated with cached on it's own? But then cli wouldn't be able to write to the volume, I think?

@lmakarov

This comment has been minimized.

Copy link
Member

lmakarov commented Aug 4, 2017

I've been doing more testing and figured out what was going on. I'm going to publish a blog post at some point, but for now, here are some key points.

osxfs:cached does not work with named volumes, so project_root:/var/www:rw,cached won't work. I reported the issue in docker/for-mac#1899

As a workaround, the following can be used:

  cli:
    ...  
    volumes:
      # Project root volume
      - ${PROJECT_ROOT}:/var/www-cached:rw,cached

Here we create another mount point without a named volume. To confirm that cached kicked in:

/Applications/Docker.app/Contents/MacOS/com.docker.osxfs state | grep $(basename $(pwd))

Do a sudo cp -a /var/www /var/www-native and now you have 3 options to test against: osxfs, osxfs:cached, native fs.

docker@cli:/var/www/docroot$ for i in {1..3}; do (time drush si -y); done
docker@cli:/var/www-cached/docroot$ for i in {1..3}; do (time drush si -y); done
docker@cli:/var/www-native/docroot$ for i in {1..3}; do (time drush si -y); done

I've also tested with the forth option: NFS with Docker for Mac. Results below.

image

cached is definitely an improvement over raw osxfs and it even outperforms the nfs mount (though, it's not clear why nfs has such a terrible (2x!) cold start time).

Looking at those results you could think "Yay! Let's all switch to Docker for Mac and use cached".

Well, let's take a look back at what VirtualBox with NFS has to offer (using the same test):

image

VirtualBox + NFS still outperforms Docker for Mac + osxfs:cached by 35%. On top of that, osxfsadds a considerable CPU overhead on the host when in use.

When comparing native file system performance between D4M (with xhyve under the hood ) and VirtualBox, D4M is as fast (or even slightly faster) as VirtualBox.

Once we add file sharing to the mix, the situation changes drastically.

It's not clear to me, why NFS results are so much different, when native fs results are pretty much the same between Docker for Mac and VirtualBox.

@lmakarov lmakarov changed the title Docker for Mac Cache Support? Docker for Mac osxfs:cached support Aug 4, 2017

@lmakarov lmakarov added this to the 1.6 milestone Nov 21, 2017

@lmakarov lmakarov self-assigned this Nov 21, 2017

@hanoii

This comment has been minimized.

Copy link

hanoii commented Jun 18, 2018

I know is an old thread, but..

@lmakarov have you ever compared the container fs vs the native fs (running all natively on macOS - apache, mysql/fs, php fpm.

For me that's always been what pushes me away of dockerized alternatives (and the fact that I am pretty used to setting my own box the way I want to). Even with docker fairly new raw mode and the cached flag, just clearing cache on drupal could be 2/3+ x slower on a bare drupal install.

@lmakarov

This comment has been minimized.

Copy link
Member

lmakarov commented Jun 18, 2018

@hanoii

have you ever compared the container fs vs the native fs (running all natively on macOS - apache, mysql/fs, php fpm.

I'm testing with a bunch of VMs (Linux, Mac and several Windows variations) running in VMware on my Mac. For day to day use I'm either on Docker for Mac or VirtualBox. Linux in VMware is as close to the native fs/etc. performance on Mac as possible (or may even outperform Mac).

The reason I'm not comparing with a native stack on Mac is due to the setup overhead. I could probably install MAMP, but for an apples to apples comparison that will still require adjustments to the settings to match them with what Docksal ships with.

For me that's always been what pushes me away of dockerized alternatives

Take a look at the Unison volumes option in Docksal:

It provides the best possible fs performance you get get out of a Docker/virtualized setup.
It does have some tradeoffs as well (like extra space usage and initial sync delay), but if performance is your biggest concerns, then it is your best bet.

I'd be very interested to see how your native stack performance on Mac compares to the Unison option in Docksal, so please share your results if you decide to try it!

@hanoii

This comment has been minimized.

Copy link

hanoii commented Jun 18, 2018

@lmakarov

A couple years ago, when docker was not yet that mainstream I set up a project-wise local environment with vagrant, debian and unison. It didn't go well, the management issues and different situations for each developer eventually made it not worth the time. But it's amazing that unison is still the solution for native performance on virtual boxes (whether virtual box or docker) at least on mac. I am unsure on the situation on Windows

I'll give it a try at some point, and attempt to compare then and give you a shout on my findings.

I really like where this, lando and other docker approaches are going and I think docker is THE tool to eventually make something consistent for local devs. I might not ever be for me. I work on a lot of projects weekly and I like having everything one bookmark away, without having to init/start/stop anything.

I am just hoping that native fs will get to docker at some point.

Linux in VMware is as close to the native fs/etc. performance on Mac as possible (or may even outperform Mac).

This is an interesting claim, and what do you use? Docksal inside a linux instance on vmware with unison between your host and vmware?

Thanks for the feedback.

@lmakarov

This comment has been minimized.

Copy link
Member

lmakarov commented Jun 18, 2018

@hanoii

and what do you use?

For the "eat your own dog food" reasons I'm sticking with the most mainstream option at the moment, which is Docker for Mac (with osxfs:cached).

When performance is a concern, I switch to VirtualBox (with NFS) - the battle tested option that has been around for quite some time. Docker for Mac + Unison is still quite experimental.

Running a Linux VM with Docksal inside is less convenient. I'm using it for testing Docksal on Linux purposes only. For daily use, I'd recommend it to Windows users, as they suffer the most from the shared/network fs performance issues.

@hanoii

This comment has been minimized.

Copy link

hanoii commented Jun 18, 2018

@lmakarov out of curiosity and to give docksal an init try I started the drupal8 example with unison volumes

Running time fin drush cr gave me an average of ~3.2s on a few calls, counting only the last to compare the same rough benchmark

While

running time drush cr on a bare install on a native stack

gives me ~1.3s

And this is just on an empty bare drupal8, I assume as more modules/themes get loaded the wider the spread would be.

and the same time fin drush cr on the non-unison volumes gives me around ~5.2s

This is all using latest docker edge

@lmakarov

This comment has been minimized.

Copy link
Member

lmakarov commented Jun 19, 2018

@hanoii Thanks for sharing the your test results. There's clearly a big gap there.

One of the tough issues with virtualized environments (meaning VirtualBox and xhyve (Docker for Mac) in this context) is the overhead of the CPU virtualization - it's expensive. For workloads that cannot be efficiently broken into multiple threads (or just don't support that) enabling more that a single core for a VM will actually slow things down (reference).

For very large databases, though, enabling multiple cores may result in better performance (as mentioned in the blog post I reference previously).

Native stacks will always have an advantage here. Though, a 250% difference like in your case is quite too much :)

What do you use for the native stack? I'm curious whether you have some specific settings/optimizations applied for PHP, MySQL, etc.

@hanoii

This comment has been minimized.

Copy link

hanoii commented Jun 19, 2018

@lmakarov I haven't done much optimizations to be honest.

It's all the latest homebrew packages: mariadb, httpd24, php7.1 (I have all 5.6, 7.0 and 7.2 installed as well at the same time, through fpm). I did turn off xdebug on my native stack and I noticed that was affecting performance but as far as I can tell, xdebug was also off on all docksal instance I tested. I didn't enable it at least and saw it was disabled on docksal.env

@hanoii

This comment has been minimized.

Copy link

hanoii commented Jun 19, 2018

I've tried lando again as well, they don't provide unison, but a brand new d8 (a bit slow to install) then took ~4.7 to clear cache. Not a huge different but a tiny better. They are using the delegated osxfs-caching instead of cached. just throwing out more info.

But still unison is a huge benefit.

@achekulaev

This comment has been minimized.

Copy link
Member

achekulaev commented Jun 19, 2018

@hanoii thanks a lot for taking your time to test this!

Could I ask you for a favor to do another test for me? You see, fin drush is slow in part because spawning an interactive session into a running container is a slow process (slow meaning 1-2 seconds overhead to spawn it).

Could you start your drupal8 example, and first open open interactive session into cli

fin bash

and only the then run time drush cr from there. This way you will test the real time of running drush inside the container, rather than time of running drush + interactive session spawn overhead.

For me the results are the following.
NFS mapped volumes ~3.5s

docker@cli:/var/www/docroot$ time drush cr
Cache rebuild complete.                                                                                                                                                                                                            [ok]
real    0m3.563s
user    0m0.810s
sys     0m0.400s
docker@cli:/var/www/docroot$ time drush cr
Cache rebuild complete.                                                                                                                                                                                                            [ok]
real    0m3.376s
user    0m0.810s
sys     0m0.380s
docker@cli:/var/www/docroot$ time drush cr
Cache rebuild complete.                                                                                                                                                                                                            [ok]
real    0m3.444s
user    0m0.810s
sys     0m0.410s

Unison volumes 1.5-2s

docker@cli:/var/www/docroot$ time drush cr
Cache rebuild complete.                                                                                                                                                                                                            [ok]
real    0m2.000s
user    0m0.730s
sys     0m0.430s
docker@cli:/var/www/docroot$ time drush cr
Cache rebuild complete.                                                                                                                                                                                                            [ok]
real    0m1.510s
user    0m0.740s
sys     0m0.180s
docker@cli:/var/www/docroot$ time drush cr
Cache rebuild complete.                                                                                                                                                                                                            [ok]
real    0m1.453s
user    0m0.750s
sys     0m0.120s

Update.
I have installed MAMP to test. All default. PHP 7.1, same drupal8 site (copied over sources).
Result is 1.5s which seems on par with Unison volumes, more consistent but not much difference in average.

11:20:36 /Applications/MAMP/htdocs/sites/default
§ time ../../vendor/drush/drush/drush cr
 [success] Cache rebuild complete.

real	0m1.587s
user	0m0.833s
sys	0m0.176s

11:20:44 /Applications/MAMP/htdocs/sites/default
§ time ../../vendor/drush/drush/drush cr
 [success] Cache rebuild complete.

real	0m1.526s
user	0m0.851s
sys	0m0.177s

11:20:48 /Applications/MAMP/htdocs/sites/default
§ time ../../vendor/drush/drush/drush cr
 [success] Cache rebuild complete.

real	0m1.513s
user	0m0.852s
sys	0m0.172s
@hanoii

This comment has been minimized.

Copy link

hanoii commented Jun 19, 2018

@achekulaev sure

I don't have nfs setup, (as I went with the native docker mac approach), but osxfs-cached:cached gives me ~3.5s within the container

and with unison ~1.35 in average vs ~1.25 in native.

That's good! I also tested it through the web interface (clearing cache) and timing just the post request and it's pretty close too. Some times it even beat the native stack.

This is promising. The next test is has to be the real thing, actually trying on an active project and do some benchmarking there, hopefully with solr,mail and maybe redis, something more "real"

I also wonder how unison would cope with composer installs/npm installs that touches a lot of files. On the lando thread where I brought thsi up, they said unison brought a lot of issues to them.

Have you ever used unison it on a full scale project? 20+modules, solr, etc.? What's your experience with it.

@achekulaev

This comment has been minimized.

Copy link
Member

achekulaev commented Jun 19, 2018

@hanoii I have used Unison to launch large scale projects (400+ modules), but mostly to verify things or do minor changes, haven't really heavily used it for development.
Some people in some situations reported issues when switching git branches, as it touches a lot of files. And you have to bear in mind, that switching git branches will need time to propagate through Unison (fin logs unison will help with the sync status).

@hanoii

This comment has been minimized.

Copy link

hanoii commented Jun 19, 2018

right. and also the fact that's duplicating everything could also be an issue if available space is somehow a constrain

@achekulaev

This comment has been minimized.

Copy link
Member

achekulaev commented Jun 19, 2018

One of the things I have in plans is the ultimate performance option. No sync + Cloud9 for editing.

  1. DOCKSAL_VOLUMES=copy option would tell fin to perform one time copy of the project folder. No follow-up syncs, just one time copy. But one would need to edit those files somehow after that. This is an issue, unless one is hardcore Vim fan, in which case it wouldn't be an issue at all.

  2. Use (currently experimental) Cloud9 IDE, which looks very appealing at this point to edit files inside container, perform commits, tests etc.

This would be the most performant option, on par with native but with all the Docksal benefits.

@hanoii

This comment has been minimized.

Copy link

hanoii commented Jul 8, 2018

@lmakarov @achekulaev can I also bother you with a slightly off topic question, but related..

What's your thoughts on the current performance with the VirtualBox option. Is it faster than docker for the time being? And vs native host filesystem. Any complains with performance on virtualbox?

Thanks!

@shelane

This comment has been minimized.

Copy link
Member

shelane commented Jul 8, 2018

@achekulaev

This comment has been minimized.

Copy link
Member

achekulaev commented Jul 8, 2018

@hanoii when mapped via NFS (the default mode) then VirtualBox is on average 20% faster than Docker for Mac, and native file system is on average 20% faster than VirtualBox.

When Unison volumes are used, then there is almost no difference between VirtualBox, Docker for Mac and Native file system.

@GMTA

This comment has been minimized.

Copy link
Contributor

GMTA commented Jul 16, 2018

@achekulaev We have had some issues with using the Unison volumes on our Macs for development. The largest two are:

  • It takes a very long time for the initial sync on large projects with lots of files (e.g. a big vendor folder that was synced back during a previous setup)
  • Sync delay can be large if there is some background operation going on

In contrast, NFS works pretty much transparently, uses less disk space and is fast. Although Docker for Mac seems to be becoming mainstream, we would be arguably worse off...

@achekulaev

This comment has been minimized.

Copy link
Member

achekulaev commented Jul 16, 2018

@GMTA I am not sure I understand you about the last phrase about being worse off. As compared to what? Which approach to chose for your project is purely your choice. There is no silver bullet. There are pros and cons with each approach.

@GMTA

This comment has been minimized.

Copy link
Contributor

GMTA commented Jul 16, 2018

@achekulaev I agree and it is subjective, but for most workloads I've seen better performance and less issues with NFS than with the Unison approach. The only real downside is lack of inotify which is largely compensated for by the improved performance.

I just now discovered that Docker for Mac can be coerced into supporting NFS together with Docksal by following instructions from this thread:
IFSight/d4m-nfs#55

Basically:

  • Configure and restart nfsd
  • Set DOCKSAL_VOLUMES to nfs
  • Disable overrides-osxfs.yml (e.g. by renaming) so the cli volume is mapped correctly

Maybe this helps someone looking for the same gains without losing sync functionality :-)

@achekulaev

This comment has been minimized.

Copy link
Member

achekulaev commented Jul 16, 2018

@GMTA ah! It was not obvious that you were advocating in favor of using NFS with Docker for Mac. It is a good point that some might be fine with it. I'm pretty sure we could add an exception, that if DOCKSAL_VOLUMES is defined by user to be NFS then fin would not override it with osxfs.

Do I understand you right?

@GMTA

This comment has been minimized.

Copy link
Contributor

GMTA commented Jul 16, 2018

@achekulaev That is completely right! There is an exception when running with DOCKSAL_NATIVE=0 which causes the override to be skipped, which is not the case when running with Docker for Mac.

In fact, the only reason to use the osxfs overrides is when you're not using DOCKSAL_VOLUMES=nfs and you're running on a Mac I guess?

@achekulaev

This comment has been minimized.

Copy link
Member

achekulaev commented Jul 16, 2018

@hanoii

This comment has been minimized.

Copy link

hanoii commented Jul 16, 2018

In this case it would be Docker with NFS? I'd be curious about that option. In theory it should have the same performance as VirtualBox and NFS, right?

@lmakarov

This comment has been minimized.

Copy link
Member

lmakarov commented Jul 16, 2018

@hanoii Docker for Mac + NFS was slower than VirtualBox + NFS in the tests done almost a year ago. See #249 (comment) for details. I should probably do another round of comparison with the recent Docker/Docker for Mac versions.

@mike-potter

This comment has been minimized.

Copy link

mike-potter commented Jul 17, 2018

I would love to see some different benchmarking here. Maybe we need a standard "suite" of tests. I see some people testing "drush si" and some using "drush cr". For NFS the big bottle neck is when you manage lots of smaller files. So I use tests like "rm -rf node_modules && npm install" or "rm -rf vendor && composer install". These kind of tests will show large performance drops for NFS, which is why I prefer either unison or osxfs.

One thing I noticed with unison is that when doing something like "rm -rf vendor" within the cli container, files on my local file system are not deleted. This is a clever workaround for a bug in unison that often causes it to crash when you quickly delete and recreate a massive number of files, but is a problem for ensuring the container and local are truly in sync.

@GMTA

This comment has been minimized.

Copy link
Contributor

GMTA commented Jul 17, 2018

@mike-potter I've been performing benchmarks on our own PHP projects with simple rm -rf vendor && time composer install invocations. On docker-machine with NFS I saw improvements of 30-40% w/ respect to osxfs:cached and on Docker for Mac I saw improvements between 20-30%. A possible explanation for this difference could be that the docker-machine has one single big NFS mount whereas the Docker for Mac approach entails configuring NFS volumes for your projects.

Anyway, not sure how recent your experience is with NFS and Docker but I would recommend revisiting your benchmarks!

@hanoii

This comment has been minimized.

Copy link

hanoii commented Jul 17, 2018

This issue's discussion is a bit too good/too useful to have it here on a closed issue. Is it too bad of an idea to highjack it, re-open/rename it and maybe link it somewhere on the project page?

@lpeabody

This comment has been minimized.

Copy link

lpeabody commented Jul 17, 2018

@hanoii I was literally thinking just about an hour ago that maybe this gets re-opened? I've been following the discussion along and enjoying the insight.

@mike-potter

This comment has been minimized.

Copy link

mike-potter commented Jul 17, 2018

@GMTA Here are my benchmarks from docker-machine with VirtualBox on Mac with rm -rf vendor && time composer install (Mac OS 10.12.4)

docker-machine + Pure Container: 25s
docker-machine + NFS: 9m40s
docker-machine + Unison: 29s

This was for a real D8 client project (based on Acquia Lightning). The dominant time for NFS was doing drupal/core although all packages were noticeably slower.

When using Docker4Mac the composer timing was:

Docker for Mac + osxfs (cached): 3m39s
Docker for Mac + without overrides-osxfs.yml: 4m59s
Docker for Mac + NFS: 3m4s

(Edited: Got NFS working with D4M) Didn't use Unison on D4M because it doesn't sync file deletions in the container which doesn't make it viable for us.

So this looks like D4M overcomes the NFS issues that docker-machine has with small files. But not seeing any big performance boost of NFS vs osxfs.

(Edited: Hmm, not sure this was really using NFS, so still learning how to use that. docker inspect still showed using bind, so the last two D4M runs were essentially the same)

(Edited: OK, got NFS working. In my "permission denied" error message it gave an IP address, so in my /etc/exports I replaced "localhost" with this IP and restarted everything. Then verified project-root was using NFS) Updated above NFS benchmark. I might not be seeing full NFS performance since I'm on older Mac OSX 10.12.4.

@achekulaev achekulaev changed the title Docker for Mac osxfs:cached support Docker containers file system performance under different scenarios Jul 17, 2018

@achekulaev achekulaev removed this from the 1.6 milestone Jul 17, 2018

@achekulaev achekulaev reopened this Jul 17, 2018

@hanoii

This comment has been minimized.

Copy link

hanoii commented Jul 17, 2018

@mike-potter I wonder why docker machine + NFS has that big of hit in comparison to the other options and that much above D4M + NFS. Shouldn't it be more or less the same underneath?

And while you are there, do you happen to be able to try that natively (on the actual host)? I'd assume it should be pretty close to the pure container benchmark.

@mike-potter

This comment has been minimized.

Copy link

mike-potter commented Jul 18, 2018

It's been over a year since I looked into it, but I remember there was an issue with PHP not caching the "stat" of files via NFS, so anything using is_dir() was slow (which resulted in patches to drush to not scan node_modules or bower_components). But I don't remember why it was so bad with VirtualBox. This was back when I couldn't get osxfs to work at all with docker-machine, so I know they have different drivers (or at least did). Been away from this for a year so things might have changed.

Unfortunately I can't run composer locally...I try to keep all my tools installed in containers and right now local composer is complaining about my PHP version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment