Robocopy features a lot of parameters. While some are well known and used, there is a maybe the most underrated parameter: /MT for multithreading. I have checked how this parameter impacts the speed.
Most Windows admins should known robocopy, then built-in copy and mirror tool from microsoft. This tool comes with a lot of parameters, some are more known and some might not be that present to all users.
For this test, I prepared the following scenarios:
- A large single file (20GB or 21.474.836.480 byte)
- 3016 Images with 7-8 MB each (~20GB or 21.473.798.962 byte)
- 73.488 text files with 400-600 KB each (~20GB or 21.486.178.224 byte)
All files are copy via network. So depending on your network and storage, the result can vary, but the general idea and improvements should apply to your setup too.
I copied the the scenarios ten times without the multi threading parameter and ten times with /MT. The other parameters were left to default (Single thread: /DCOPY:DA /COPY:DAT /R:1000000 /W:30. Multi thread: /DCOPY:DA /COPY:DAT /MT:8 /R:1000000 /W:30)
Large Single File
The large single file copies pretty fast (compared to the other files):
The average is below 500 seconds (499,8) with a maximum of 612 seconds and a minimum of 450 seconds.
I would expect multi threading to have little to no impact to the speed in this scenario.
But I was wrong:
The speed nearly doubled: The time required dropped to 255,7 seconds average with a maximum of 289 seconds and a minimum of 224 seconds.
The copy job for the image files took significantly longer than the single file: The average was 841 seconds with 770 seconds the fastest and 946 seconds the slowest.
I would assume that multithreading helps here a lot as we have several files to copy. But the impact was not as good as with the single file: The average dropped to 489 seconds, which is 58% of the singlethreaded time (Compare: The single file multithread job took 51%).
Copying so many small files takes awfully long compared to the other jobs: The average was 4860 seconds or nine times longer than the single file job.
But here is the greatest time saving possible: Multithread took only 849 seconds or 17% of the original time.
From my test and my experience using the /MT parameter won’t hurt but can easily speed up your jobs. So whenever possible, us it or let me know if you know a scenario, where multithreading is a bad idea to use.