It may seem logical that running several profiles at the same time would complete faster than running them one after another. In practice, the opposite is often true. Running multiple profiles simultaneously can cause all of them to run slower, and the total time to complete all profiles can be longer than running them in sequence. This article explains why this happens and when parallel execution is beneficial.
Why Simultaneous Profiles Can Be Slower
Hard Drive Contention
This is the most common cause of slowdowns. Traditional hard drives (not SSDs) have a single read/write head that must physically move to access different parts of the disk. When one profile is reading or writing files, the head moves sequentially through the data, achieving speeds of 100 MB/s or more.
When two or more profiles access the same hard drive at the same time, the head must constantly jump between different areas of the disk to serve each profile in turn. This random access pattern can reduce effective throughput from over 100 MB/s down to 10-20 MB/s or less. The drive spends more time seeking between locations than actually reading or writing data.
For example, if two profiles each take 10 minutes when run alone, running them simultaneously on the same hard drive might take 15 to 25 minutes total, because both profiles are fighting for the same disk head.
Network Bandwidth Saturation
If multiple profiles are reading from or writing to network storage over the same network connection, they share the available bandwidth. Two profiles each trying to transfer data at 110 MB/s over a 1 Gbps connection will each get roughly 55 MB/s, taking approximately twice as long per profile. The total time is roughly the same as sequential execution, but with added protocol overhead it is often slightly worse.
FTP and SFTP connections are particularly affected because most servers limit the number of simultaneous connections or throttle bandwidth per connection. Cloud storage providers impose API rate limits that apply across all connections from the same account, so multiple profiles accessing the same cloud account will hit these limits sooner.
Memory Pressure
Each running profile consumes memory for its file lists, comparison databases, log buffers, and working data. When multiple profiles run simultaneously, the combined memory usage can become substantial, especially for profiles that scan large directory trees with hundreds of thousands of files.
If the total memory usage exceeds available physical RAM, Windows begins paging memory to disk. This dramatically slows down all running profiles because every memory access may require a disk read. On a system with a hard drive (not an SSD), paging can reduce performance by an order of magnitude.
CPU Contention
While CPU usage is rarely the primary bottleneck for file copying, it becomes significant when multiple profiles are simultaneously performing hash calculations (for verification or integrity checking), compressing files into Zip archives, or encrypting data. These operations are CPU-intensive, and running several in parallel can saturate the available CPU cores, causing all profiles to slow down.
Log File and Database Contention
Each profile writes to its own log file and updates the Fast Backup database. When multiple profiles run simultaneously, these write operations compete for disk I/O. If the log files and databases are stored on the same drive as the source or destination files, this adds further contention.
Lock Contention on Shared Resources
If two profiles access overlapping sets of files or folders, one profile may need to wait for the other to release a file lock before it can proceed. This is particularly common with Volume Shadow Copy (VSS) operations, where only one shadow copy can typically be created at a time.
When Simultaneous Execution Is Beneficial
Running profiles in parallel can be faster when the profiles access completely independent storage devices and network paths. For example:
- Profile A reads from a local SSD and writes to Cloud Provider X.
- Profile B reads from a different local SSD and writes to an FTP server on a different network.
In this case, there is no contention between the profiles and both can run at full speed. The total time is roughly the time of the longest profile, rather than the sum of both.
SSDs also handle simultaneous access far better than hard drives. Because SSDs have no moving parts, they can serve multiple concurrent read and write streams without the severe performance degradation caused by disk head seeking. Running two or three profiles simultaneously against an SSD is often faster than running them sequentially.
Recommendations
Use Groups to Run Profiles in Sequence
SyncBack allows you to create a Group profile that runs multiple profiles in a defined order. By default, profiles in a group run one after another. This ensures that each profile gets full access to the storage and network without contention. The total time is predictable and usually shorter than running the same profiles simultaneously.
Identify the Shared Bottleneck
Before deciding whether to run profiles in parallel or in sequence, consider what resources they share:
- Same source or destination drive: run sequentially, especially if it is a hard drive.
- Same network connection to the same server: run sequentially.
- Same cloud storage account: run sequentially to avoid hitting API rate limits.
- Completely independent storage and network paths: running in parallel may be faster.
Separate Storage Where Possible
If you need profiles to run in parallel for scheduling reasons, consider placing the source and destination data on separate physical drives. This eliminates the most common bottleneck. Using SSDs instead of hard drives also significantly reduces contention.
Monitor During Simultaneous Runs
If you notice that running profiles simultaneously is slower than expected, check the following:
- Disk usage in Task Manager: if a hard drive is at 100% utilization with high response times, disk contention is the cause.
- Memory usage: if physical memory is nearly full and the page file is in heavy use, memory pressure is the cause.
- Network usage: if the network adapter is near its maximum throughput, bandwidth is the cause.