Same issue here. Would appreciate some feedback on when this is going to be resolved.
I also tried d4m-nfs but couldn’t get it to work.
Myself and my colleagues are also pretty desperate to see a resolution. We are using docker for our local development environments and CI. We would rather not have to use external dependencies other than docker for mac as it would be a fairly large overhead for a new developer. Especially a junior one.
We are using d4m-nfs but don’t see it as a sustainable solution.
Good luck with it and hope you can solve it! We’ll have our fingers crossed.
@damau I am hoping d4m-nfs is only a temporary work around, you are correct in saying it is not very sustainable. When there are changes to the Docker for Mac Moby VM we have had to tweak d4m-nfs and I believe currently it only works with the stable release not the current beta. It is odd to dream of the deprecation of software you have written 
.
I am curious if those at Docker are considering incorporating the solution path in d4m-nfs or some other alternate solution to fix the performance issue. Is there a roadmap for a fix that will be built-in?
Here is an alternate approach, which modifies the ramdisk:
gulp watch on mac is unbearable, I’ve tried everything, but its time to go back to native nodejs unfortunately.
for all other containers I use docker-sync which is a hassle but makes development bearable.
Thank you so much @fulcrum
I implemented this yesterday and now have near native performance on the Mac. Docker Sync did not work for me.
Swapping out osxfs for nfs was the only thing that made any difference to performance for me.
All projects now run like a dream.
The only thing that concerns me is that this solution doesn’t work on the upcoming 1.13 release of Docker. Will d4m-nfs be updated to work with the new version of Docker? Are you able to expand on why it does not work and what steps need to be taken to update d4m-nfs?
Once again - many thanks for a great solution!
Tony
"The only thing that concerns me is that this solution doesn’t work on the upcoming 1.13 release of Docker. "
More concerning is docker has gone silent on this issue and there is no telling if this will ever be fixed.
Maybe tweeting docker directly might bring some attention to this issue? https://twitter.com/docker
We’ve been struggling with osxfs speed issues since beta and I’ve started suggesting developers move over to native Linux. Docker for Mac is a nice idea but not usable if you’re developing in a container setup. The silence is not encouraging.
This fileshare thing is really annoying … I’ve tried docker-for-mac-nff by @stephank and d4m-nfs by @fulcrum and with my symfony project it’s still not working like it should (or maybe I made something wrong, but since I removed User folder from docker settings nfs mount works, because everything is mounting OK) …
I made a little test - without nfs my project even wont build (composer will fail), on nfs solutions pageload is really slow (7-15s), but when in Dockerfile i made a COPY of files into container (without mount) then pageload is ~1s (assigned 1 core and 6GB ram for docker) …
That’s on MBP13" early 2015 with i5 2.9GHz, M2 HDD and 16GB Ram …
I don’t now why even NFS is performing so bad … can I make some kind of test to be 100% sure that NFS is on place?
I too tried out @stephank’s docker-for-mac-nfs yesterday and ran into some initial problems (because I think I did something wrong at first, not because there was a problem with his instructions), but I was able to debug and solve my problems by logging in directly to the docker host VM and poking around there. @stephank’s blog post (https://stephank.nl/p/2017-01-01-inside-dockers-moby.html) and the other blog post he linked from there (http://lucjuggery.com/blog/?p=753) were very helpful for me.
I haven’t done extensive testing yet, but I can verify that docker-for-mac-nfs is working well for me in that it was pretty easy to set up, it is in fact working (I can view and modify shared files), and the performance is not as abysmal as it is with osxfs. I’m not sure how close the performance is to native, but for my purposes it doesn’t matter all that much.
Thank you very much, @stephank for this great, well documented solution! (Though hopefully it is only temporary until Docker for Mac is finally fixed for real. =P)
1 Like
@jonathak NFS is about 3-5 times slower then native speed, that is why http://docker-sync.io is not using NFS at all - a proper sync is used. One other problem with NFS is the permission issue (uid/gid)
@barat Using a sync solution ( 2 way ) like unison, docker-sync provides native performance, so as there would be no share at all. You will be back to ~1s on page load with it
This makes a difference esp. with a lot of PHP based projects, since NFS becomes even worse with reading a lot of smaller files, which PHP frameworks like Symfony or Drupal tend to have ( out of the PHP DNA).
It also seem to have a big impact on bigger Java-Frameworks, when compiling happens.
Also projects with a huge NPM dependency tree (which gets this way very fast…) tend to be very slow with NFS. It seems like NFS degrades very fast with the number of files.
I do not understand why people really wait for a solution in docker for mac. Folder-Sharing performance is a huge topic, neither Oracle nor VMware are able to cope with it on a level, where it would by any means suite development.
That said, are you really believing Docker can at any level compete with a company which involves experts on paravirtualization ONLY?
The reasons why things gone silent here is, because Docker already knows, they will not be able to get anything big happen in this. They are not able to provide 1/50 of the ressources VMware dedicates to their solution like Fusion.
I see myself, there are a lot of suggestions in my writing, but lets say, there are some facts and odds to cover this one up.
That said, people stop complaining here again and again. Either pick a different solution then d4m, pick a workarround like a NFS based one or a docker-sync like, or move to linux.
1 Like
Your right. The only solution is for apple to implement namespaces and cgroups in kernel like linux does. They should be working with apple, not wasting resources on a lost cause.
In other words docker for mac is completely unable for it’s primary use case 
Docker you make me laugh and cry.
Does docker on windows suffer from the same problems?
In the meantime, for the millions of developers with mac laptops that can’t immediately switch over to linux laptop, and want to use containers for local development environment to build java/node/ruby/php apps. What’s the current best option?
Linux in a virtualbox vm?
2 Likes
I completely agree, I’ve ran into the same performance issue with VirtualBox using NFS with Drupal projects (switched to rsync, then switched again to a plugin called gatling-rsync-auto – for performance reasons).
I would like to see D4M include a de-facto solution (docker-sync seems like the best option to me) so that end users aren’t forced to spend countless hours researching to come to the same conclusion.
2 Likes
I gnashed my teeth for about 24 hours on this problem before coming to a simple solution for my case: simply don’t sync when not necessary. I’m sure this doesn’t work for everyone – but in case your issue is analogous:
I set up a development environment including traefik, ember-cli and some data services. Ember-cli has the package directory mounted and uses ember serve to serve. It takes 8-10 times longer set up this way. However, mounting the ./tmp and ./dist subdirectories as tmpfs volumes gives me almost all the time back.
services:
web:
build: "$PWD/services/crane-wisdom"
image: "cws/wisdom"
volumes:
- $PWD/services/crane-wisdom/crane-wisdom:/home/docker/app
- $PWD/services/crane-wisdom/crane-wisdom/docker_node_modules:/home/docker/app/node_modules
- web_temp:/home/docker/app/tmp
- web_dist:/home/docker/app/dist
links:
- server
command: [
"ember", "serve", "--proxy", "http://server:16006",
"-lr", "false" ]
depends_on:
- server
labels:
- traefik.port=4200
- traefik.frontend.rule=Host:localhost
# create temporary volumes for ember-cli compile to avoid
# slow sync back to host
volumes:
web_temp:
driver_opts:
type: tmpfs
device: tmpfs
web_dist:
driver_opts:
type: tmpfs
device: tmpfs
Sorry Docker, I give up on you
2 Likes
I like to mention that there is still the docker-toolbox which does not experience these performance issues. I use it for some php projects and the loading times are 5 to 10 times faster using virtualbox and even faster using vmware fusion.
nemo64 of course it does, its a share though vbox, considered to be ultra slow with bigger projects, see https://github.com/EugenMayer/docker-sync/wiki/Alternatives-to-docker-sync in the lower section. vbox nativ with toolbox is usually far worse then docker for mac is, so its by no means better.
1 Like
But it is. I used boot2docker a year ago and i can confirm that is was so slow that i used nfs instead. But the newer virtualbox versions have better shared folders which in my experience are on the same level as nfs shares. As I said, I have symfony and typo3 projects running with docker on a mac. I tested a typo3 project with 5200 php files and cache disabled (although still not all are used for a request).
This is the an apache benchmark result for a page with docker for mac:
Percentage of the requests served within a certain time (ms)
50% 2029
66% 2130
75% 2223
80% 2292
90% 2474
95% 2593
98% 2699
99% 2735
100% 2735 (longest request)
This is the same request with the same benchmark and the same configuration but using docker-toolbox:
Percentage of the requests served within a certain time (ms)
50% 561
66% 584
75% 613
80% 621
90% 691
95% 737
98% 796
99% 880
100% 880 (longest request)
I don’t have php 7 natively installed and I can’t easily reproduce this environment natively… I could try to start docker completely within a linux vm but I think my point is already clear. I would try the docker-toolbox.
EDIT: I thought I add some information: I used docker for mac Version 1.13.1-rc1-beta40 and docker-toolbox with the vmware fusion driver.