A common developer workflow when using frameworks like Symfony or React is to edit the source code using a Windows IDE while running the app itself in a Docker container. The source is shared between the host and the container with a command like the following:
$ docker run -v C:\Users\me:/code -p 8080:8080 my-symfony-app
This allows the developer to edit the source code, save the changes and immediately see the results in their browser. This is where file sharing performance becomes critical.
The latest Edge release of Docker Desktop for Windows 184.108.40.206 has a completely new filesharing implementation using Filesystem in Userspace (FUSE) instead of Samba which:
- uses caching to (for example) reduce page load time in Symfony by up to 60%;
- supports Linux inotify events, triggering automatic recompilation / reload when the source code is changed;
- is independent of how you authenticate to Windows: smartcard, Azure AD are all fine;
- always works irrespective of whether your VPN is connected or disconnected;
- reduces the amount of code running as Administrator.
Your feedback needed!
This improvement is available today in the Edge 220.127.116.11 release and will roll-out to the stable channel later once we’ve had enough positive feedback. Please download it, give it a try and let us know how it goes. If you discover any problems, please report them on GitHub and make sure you fill descriptions and reproduction steps so that we can quickly investigate.
Big performance improvements
Performance is vital when application source code is being shared between the host and a container. For example when a developer uses the Symfony PHP framework, edits the source code and then reloads the page in the browser, the web-server in the container must re-read many PHP files stored on the host. This must be fast.
The following graph shows the time taken to load a page of a simple symfony demo in three configurations:
- Previous version: this is the implementation in earlier versions of Docker Desktop
- Docker Desktop Edge 18.104.22.168: this is the new (faster!) implementation
- In-container: the files are not shared from the host at all, instead they are stored in the container to show the upper limit on possible future performance.
The two bars on the left hand side show the latency (in seconds) using an older version of Docker Desktop. Note that the second fetch is only slightly better than the first, suggesting that the effect of caching is small.
The two bars on the right hand side show the latency when the files are not shared at all, but are stored entirely inside the VM. This is the upper limit on performance if the volume sharing system were perfect and had zero overheads.
The two bars in the middle show the latency when the files are shared with the new system in Docker Desktop Edge 22.214.171.124. The initial (uncached) fetch is already better than with the previous Desktop version, but the second (cached) fetch is 60% faster!
As well as big performance improvements, the new implementation has the following additional benefits:
- The new version can’t conflict with organisation-wide security policies as we don’t need to use Administrator privileges to share the drive and create a firewall exception for port 445.
- The new version doesn’t require the user to enter their domain credentials. Not only is this fundamentally more secure, but it avoids the user having to re-enter their credentials every time they change their password. Many organisations require regular password changes, which means the user needed to refresh the credentials frequently.
- The new version supports users who authenticate via a smartcard, or AzureAD or any other method. Previously we could only support users who login with a username and password.
- The new version is immune to a class of problems caused by enterprise VPN clients and endpoint security software clashing with the Hyper-V network adapter.
Stay tuned for a follow up post that deep dives into the new Docker Desktop filesharing implementation using FUSE.