Docker Desktop 2.2+ incredibly slow performance with host volume mounts

Question

I've got a build which is quite intensive in terms of file io. It involves 70k loose files as well as a fair amount of zipping/unzipping.

The performance of this build plummets when run inside of a Docker Desktop 2.2+ container using host volume mounts.

12 minutes - Straight Windows 10

19 minutes - Docker Desktop 2.1.0.5 against host mounted volume (Windows /c drive)

71 minutes - Docker Desktop 2.3.0.2 against host mounted volume (Windows /c drive)

2 minutes - Docker Desktop 2.1.0.5 against container file system

2 minutes - Docker Desktop 2.3.0.2 against container file system

Even with Docker 2.1.0.5 against host volume mount the performance wasn't great. But with DD 2.3 going from ~19 minutes to ~71 minutes is mind numbing.

Anyone else seeing this kind of performance hit on file io intensive tasks?

Answer 1

Take a similar project and had the same problem, I decided to do something simple that is equivalent to the same solution as the docker mount point for developers:

1 - Check if the container has the rsync tool, if not install it.

2 - Generate a shell script file via dockerfile with the following instructions:

WORKDIR /var/www/html
RUN mkdir -p /folder-shared
RUN echo "#!/bin/bash" > sync-windows-files.sh
RUN echo 'while true; do' >> sync-windows-files.sh
RUN echo '  rsync -avu "/folder-shared/" "/var/www/html"' >> sync-windows-files.sh
RUN echo '  sleep 2;' >> sync-windows-files.sh
RUN echo 'done' >> sync-windows-files.sh
COPY . .

Add the command to the last line to run it in the background:

CMD ["bash", "-c", "sh sync-windows-files.sh &]

Note: My web server is looking at /var/www/html, dockerfile should always be in the project root, to speed up the process.

3 - Prepare DockerCompose.yml:

services:
  regulacao:
    container_name: shared-windows-files
    build:
      context: .
      network: host

    volumes:
      - ./:/folder-shared
    working_dir: /var/www/html/
    ports:
      - "8587:80"

Explanation: The workaround for this problem is to map the docker share to another directory, in this case the directory called folder-shared was created in the root of the container image during the build. Once you've mapped the directory, you create a shell script sync-windows-files.sh that performs an infinite loop synchronising the files from the folder-shared shared folder to the folder where the webserver will point, in my case /var/www/html.

By doing this the problem was successfully solved, I hope you can understand.

Answer 2

True story, x10 times slower in mixed load (reads/writes) according to my benchmarks.

Although they promise Linux subsystem to be way faster, it still looks to be a grey area.