Performance Testing WebDAV Clients

Part of migrating applications from on-premises hosting to cloud hosting (AWS, Azure, etc) involves re-evaluating how users access their data. A recent migration for one our federal clients involved users running Windows 10 accessing a Windows file share using the SMB protocol (SMB is the Windows built in file sharing protocol used commonly for shared drives). Since SMB isn’t safe to run directly over the Internet (it’s usually not encrypted and it has a long history of security vulnerabilities), potential options included tunneling SMB within a VPN or changing away from the SMB protocol. One such alternative is WebDAV.

Web Distributed Authoring and Versioning (WebDAV) provides the same basic functionality as other file sharing protocols (such as NFS, SMB, and FTP) except it is over the familiar, widely deployed well supported HTTP protocol. It was literally designed for this use case.

Testing Methodology

We will look at  seven approaches for clients to access a WebDAV share, evaluating and testing the performance of each.

In March 2019, testing was performed on the same client, same server, and using the same connection.

The client computer is a Dell Latitude 7490 running Fedora 29. Windows 10 (version 1809 build 17763.348) was run as a Virtual Machine in KVM using user mode networking to connect to the Internet. For certain tests, Docker was used in Linux and the Windows 10 VM connected to it.

The WebDAV server is a server computer with a Intel i5-6500 CPU. It is running Apache Web Server 2.4.38 and Linux kernel 5.0.0-rc8. The WebDAV site is served over HTTPS.

Ping time between them is 18ms average, httping to the WebDAV server URL is 140ms average. These times are in line with expectations for a consumer grade network connection.

Windows 10’s Redirector over HTTP/1.1

WebDAV Redirector is the name of the built in WebDAV client in Windows. It’s accessed from Windows Explorer by using the “Map network drive…” option and selecting “Connect to a web site that you can use to store your documents and pictures.”

Recent versions of Windows 10 support HTTP/2, so for this test, the “h2” protocol was disabled on the Apache server.

Windows 10’s Redirector over HTTP/2

This test was the same as the previous, except we enabled the “h2” protocol on the Apache server.


WebDrive (version 2019 build 5305) was used with “Basic Cache Settings” set to “Multi-User.” All other settings were left at their defaults.

To note, WebDrive does not currently support TLS 1.3 or HTTP/2, which would likely improve performance.

davfs2 on Linux

davfs2 is a Linux file system driver that allows mounting WebDAV shares just like any other file system.

For this testing, the client is Linux, not Windows 10. Therefore, this test isn’t a complete solution (the requirements state that clients need to run Windows). This test provides information about one component of a complete solution (it covers just the davfs portion of the Samba + davfs solution). This isolated information permits greater understanding of the complete solution.

davfs2 does not support HTTP/2, but offers a number of configuration options. Here’s what was used for this testing:



use_locks 1

delay_upload 0 # disable write cache so users know that when the UI tells them the upload is done it’s actually done

And the mount command:

sudo mount -t davfs /home/candrews/webdavpoc/ -ouid=1000,gid=1000,conf=/home/candrews/.davfs2/davfs2.conf

The davfs2 version is 1.5.4.

davfs2 with locks disabled (using a Linux client)

This test is the same as the previous one, but with WebDAV locks disabled by setting “use_locks 1” in davfs2.conf.

Samba + davfs2

In this test we used Samba to expose the davfs2 mount from the davfs2 test and useds Windows 10 to access the result SMB share.

The davfs2 mount exposed using SMB with the dperson/samba docker image using:

name smb -e USERID=1000 -e GROUPID=1000 –security-opt label:disable -v /home/candrews/webdavpoc:/webdavpoc:Z –rm -it -p 139:139 -p 445:445 -d dperson/samba -s “webdavpoc;/webdavpoc;yes;no;no;testuser” -u “testuser;testpass” -g “vfs objects =”

The biggest challenge with this approach is with regards to security. The davfs2 mount that Samba exposes uses fixed credentials – so all Windows 10 users using the smb+davfs proxy will appear to the WebDAV server to be the same user. There is no way to pass through the credentials from the Windows 10 client through Samba through davfs2 to the WebDAV server. 

samba + davfs2 with locks disabled

This is the same as the previous test, but here WebDAV locks have been disabled in davfs2.


Here are the takeaways from the above results:

  • The built-in Windows Redirector (which is free and the easiest solution to implement) is by far the slowest.
  • WebDAV benefits greatly from HTTP/2. HTTP/2 was designed to improve the performance of multiple concurrent small requests (as is the case of HTML, which references and therefore causes many requests of CSS, Javascript, and images), and that’s exactly how WebDAV works. For each file operation via WebDAV, internally WebDAV issues multiple requests. In the case of a download, each file is a PROPFIND and a GET. For uploads, each file is a PROPFIND, PROPPUT, PUT, and, if locking is enabled, LOCK and UNLOCK. For example, downloading 10 files using WebDAV will result in 20 requests. Allowing these requests to be done concurrently / at the same time speeds things up.
  • Disabling WebDAV locks improves performance. By eliminating the LOCK/UNLOCK requests for every file, upload performance doubled. Unfortunately, disabling WebDAV locks for the built in Windows Redirector requires a registry change, which is a non-starter for many organizations. WebDrive has locks disabled by default and davfs2 only uses locks when editing files (i.e. when a program actually has the file open for writing), not when uploading a new file.
  • Surprisingly, the overall fastest approach, by far, involves a middle box running Linux using smb+davfs2. Adding another system through which the traffic must pass and another protocol usually slows things down, but not in this case. davfs2’s greater efficiency outweighs the cost of the additional complexity.
  • Because davfs2 opens more HTTP connections, it allows for more requests in parallel, making it a very fast option. WebDrive supports adjusting the concurrency too; in “Connection Settings” there are settings for “Active Connections Limit” (defaults to four) and “Active Upload Limit” (defaults to two). Adjusting these settings would impact performance.
  • The client/server connection was ~100 Mbps (megabits per second) with ~18 ms (milliseconds) of latency. Lower bandwidth and high latency would result in even greater benefits from using HTTP/2 and disabling locking.

Here are some considerations for future research and testing:

  • AWS Storage Gateway may be a solution worth exploring. However, concerns for this approach include:
    • Incompatibility with MITM HTTPS-decrypting security devices
    • Use of a local, on premises cache (called an “upload buffer” in the documentation) resulting in changes that are not immediately available globally
    • Requires the use of S3 for file storage, which may not be compatible with the servers in AWS
  • Various other WebDAV clients for Windows, such as DokanCloudFS, NetDrive, DirectNet Drive, ExpanDrive, and Cyberduck / Mountain Duck, are available. They could be evaluated as potential solutions.
  • Further tweaks to configuration options, such as the concurrency settings in WebDrive and davfs2ww