-
Notifications
You must be signed in to change notification settings - Fork 39
Document new edge caching flag in docker #9
Comments
I saw this, but until I have time to do some benchmarks, I'm not entirely convinced that the new functionality solves the problem. It's a bandaid at best, and it would really only improve read speeds inside the container. Don't get me wrong - this is a good thing, but it doesn't fix (for example) At the very least, the improvements in read speed should make this container run a bit faster :) |
I agree, I don't think it's a solution to everything - Although I would look into yarn or to store the npm cache stuff in something that isn't mounted, but that's not the point - it should be seamless. You shouldn't need to worry about that stuff. I think the addition to this helps more than any improvement so far. Mostly it improves where running code. (In for example Symfony for example, where it's a lot of files loaded on every request). It does solve write speeds, there's going to be :delegated. Although that's technically not as "reliable" but I can see myself using it for things like the npm writing. Overall it just narrows the case where this is needed which is a good thing overall. |
|
Just adding a note here that With NFS volumes, the host computer setup can be a little annoying (especially on macOS Catalina, with potential permissions issues), but it's smooth sailing once it's set up. With this sync setup (docker-bg-sync), you have to wait for the (somewhat lengthy and CPU-stressing) initial sync before doing anything, and allow a 3rd party docker container to run with Still wish Docker team could make |
I wish they could make it open source so that other people could make it faster. They've demonstrated that they can't or won't. :( I'd love for this project to be totally unnecessary. NFS kind of gets there, which is nice, but it's certainly not an easy solution.
You don't necessarily need to do this. You just need to if you want more inotify watches than what you get by default. |
I guess I'm unclear on what inotify watches do, then; the default according to my logs was 8192 (or thereabouts); does that mean unison will only watch 8192 of the 32,000+ files that were in my Drupal codebase, and only synchronize changes in those files? If so that makes the sync kind of useless in my case (without |
Yep, that's correct. But if you have fewer than 8192 files, then running this container with |
True true, not everyone's PHP or other non-Drupal projects have zillions of dependencies with hundreds of files each :) FYI I made my private codebase public so I can share the test results for NFS vs this vs everything else I've tried; see these two issues for the process and the benchmarks:
tl;dr this utility is neck-in-neck with docker-sync (though easier to set up IMO), and similar in overall speed to NFS (initial sync taking a long time, and some quirks encountered thereafter), though faster in the long run. And of course it's about 2-4x faster than |
In case you didn't know, docker-for-mac has got a very much needed flag which makes this container not as needed, thankfully. :cached is implemented now and :delegated I think will be soon. They added a blog post now as well. Maybe get a link to it in the readme?
https://blog.docker.com/2017/05/user-guided-caching-in-docker-for-mac/
The text was updated successfully, but these errors were encountered: