The results of changing volume type were disappointing, I was hoping for a simple change to the instructions and a happy developer community. I tried a second run to see if the caching performance would speed up the reads but the results did not really change.īelow shows time taken for compile with two runs for the same program.ĭocker run -i -t -v $(pwd):/build:cached builder realĕm56.335s Once again the performance was improved on the default type, but not where we wanted it, and slower than the delegated volume type. Next up was to try the cached type to see the performance benefits.
Starting with delegated which seemed the most promising, the times did improve, but nowhere near where we needed to be in terms of performance.ĭocker run -i -t -v $(pwd):/build:delegated builder realĕm15.195s With the learning from the Docker documentation, I started working through the different volume types hoping to see some healthy performance gains. The delegated configuration as its name suggests delegates authorisation of the writes to the container view, meaning writes are not written to OS disk immediately and losing the container could result in data loss. This one seemed good for our use case as we loop over the same files for the build process.
The cached configuration as the name suggests keeps data read from the OS volume in a cache to be used on repeat operations. While running Docker on Linux I had never changed this value, Linux using native hooks to handle volumes means this type is rarely deviated from when running native Linux. The consistent configuration Forces the container volume to be synchronised with the local OS directory, lowering performance to increase data protection. I decided to try all types getting results I thought I would be happy with.īind mount volumes in Docker can be broken down into three types:Įach type lowers the consistency with the local operating systems respectively. Volume typesĮagerly reading through the documentation to figure out where I should spend my time, it became obvious that changing volume type was very easy. Our build process would not suffer from issues with data synchronisation, so I believed this path would be a simple fix to the performance issue.ĭocker Docs had a whole section dedicated to this topic due to the pervasive nature of the issues seen on macOS. This would be a risk of data loss compared to speed improvements. Searching around I was able to find some information to change the type of mount Docker uses to speed up performance by limiting the synchronisation with the local OS.
The complaints were understandable, we were trying to decrease the time developers spent trying to build code, not make it a lot worse. Using the basic time command to compare compilation times shows the discrepancy clearly.Ĭomplaints started to come back to my team after we tried to push local Docker compiling for the development teams.
This is a pain for us as we try to empower our developers to get fast feedback locally and rely less on specific infrastructure dependencies when building their code.
Docker macos mac#
This process is over 10x slower when running local with Docker when compared to running on one of our build servers.Įven with more CPU cores on local Mac with faster clock speeds, the speed to compile is much slower locally when compared to the build sever. The build process loops over many files to build out the required methods to inject into the compiled binary. This can be seen with a compile of a program locally compared with the server-side build time. This raises an issue with performance when trying to bind mount a volume to Docker from the local Mac environment.įile system performance for bind mounts is poor when running Docker for Mac.
Docker macos for mac#
With widespread macOS adoption for developers at reecetech, it became important for us to solve a well-known issue with Docker bind volumes performance when using Docker for Mac.ĭocker for Mac uses a Linux VM to perform Docker operations, acting as a shim between Docker and the macOS kernel.
0 kommentar(er)
