SharePoint Server 2016 Drag and Drop Control is Limited to 70Mbps

The SharePoint Server 2016 drag and drop control is limited to roughly an 8MB/s upload in the RTM and April builds when uploading a file in excess of 100 MB. Testing with files greater than 1GB will allow you to better see the transfer rate over a sustained period of time; I tested with Fedora-Live-Workstation-x86_64-23-10.iso which is 1,434,624 Kb, a file under the 2047 Mb limit allowed by SharePoint Server 2013 to make a direct comparison.

The test hardware here was identical for both VMs. Backend virtualized SQL Server is in use by both VMs. All VMs reside on the same Hyper-V host. Each VM has an equal amount of vCPUs (4) and vRAM (13 GB) allocated, along with the entire environment running on SSDs (SQL Server VM on a separate volume from the SharePoint VMs). Over CIFS, all three VMs, SharePoint Server 2013, SharePoint Server 2016, and the SQL Server transfer at near wire speed of 113 MB/s, or approximately 904 Mbps. The VMs and Hyper-V host all run on Windows Server 2012 R2.

These methods are not fully scientific, they’re more or less rough estimates, but ‘good enough’ to show the performance disparity between the platforms.

Here is a transfer to SharePoint Server 2013 using the drag and drop control.


The maximum sustained transfer rate was approximately 786 Mbps.

SharePoint Server 2016, out of the box.


A quite odd see-saw effect, with a maximum transfer rate of approximately 73 Mbps. This upload takes forever.

And finally, SharePoint Server 2016 with an adjusted drag and drop control.


Even better than SharePoint Server 2013, with a maximum sustained transfer rate of 979 Mbps! Nearly wire speed!

Because this requires an adjustment of a file in the 16 hive, I’m not going to recommend you make any changes to your farm implementation, but just be aware that large files in SharePoint Server 2016 may not upload as fast as you may have previously been used to with SharePoint Server 2013. For SharePoint Server 2016, this also impacts the standard ‘Upload’ control, if you choose to use that instead of the drag and drop method.

My assumption for this ‘limit’ imposed on SharePoint Server 2016 comes from the Core.LargeFileUpload PnP library. There is a note at the bottom of the readme.

Internal testing has shown that a slice size of 8 MB works best, but of course this depends on the network connection you’re using

This, of course, works out to about the performance we see. SharePoint Server 2016 uses the same StartUpload, ContineUpoad, and FinishUpload CSOM methods as outlined in that particular library (Method #3).

I don’t know if the PG will make changes to the drag and drop control to improve performance for clients. I can certainly see why this makes sense in a SharePoint Online environment, but in a SharePoint on-premises environment, where network connectivity may equal or exceed 1 Gbps, it is a hindrance.

Trevor Seward is a Microsoft Office Apps and Services MVP who specializes in SharePoint Server administration, hybrid scenarios, and SharePoint Online. He has been working with SharePoint for 16 years from SharePoint 2003 on up, managing environments with terabytes of content for 150,000+ user organizations. Trevor is an author of Deploying SharePoint 2016 and Deploying SharePoint 2019. You can find him on Twitter and in /r/sharepoint.