TNCA-0002 – The ChronoAgent Performance Advantage
Created: May 14, 2014 | Updated: July 06, 2020
It is often claimed that using ChronoAgent in conjunction with ChronoSync to perform Mac-to-Mac backup and synchronization offers a significant performance advantage over standard file sharing. That sounds great but what exactly does it mean? Proclaiming an absolute performance figure such as “Twice as Fast!” is very hard to do since no two synchronization scenarios are the same. Differences in computing hardware, networks, data sets and usage patterns can cause the performance figures to vary greatly.
In an effort to provide at least some indication of the performance benefits you’re likely to see by using ChronoAgent, we’ve constructed a series of tests that pits ChronoAgent against the file sharing protocols that are built in to macOS. While we can’t promise you’ll see exactly the same kind of relative performance presented here, we can say that you are very likely to obtain better performance with ChronoAgent versus built-in file sharing. As they say in the automotive industry, your mileage may vary!
HOME DOCUMENTS BENCHMARK
This test is designed to simulate the daily synchronization of a modest collection of documents that would be found in a typical user’s home folder. It consists of approximately 39,000 files & folders totaling 8.4 GB of data. The file types run the gamut from small text and word processing documents, medium size spreadsheets, presentations, illustrations and photos, to large movie and disk image files.
TEST CONFIGURATION
All tests were conducted using ChronoSync v4.5.0 on a 2.26 GHz 8-core Mac Pro (Early 2009) with 16 GB RAM, running macOS v10.9.3. The destination was an external FireWire 400 RAID connected to a 2.53 GHz Mac Mini (Late 2009) with 4 GB RAM, running macOS Server v10.9.2. Network connectivity was provided via wired, 1GB Ethernet. The destination ChronoAgent was a pre-release build of version 1.5.0. Both SMB and AFP file sharing were the built in macOS implementations. The SMB2 protocol is automatically used for Mavericks-to-Mavericks connectivity and is thus the default type of file sharing connection that most users would employ.
Two types of ChronoAgent connections were used for these tests: standard and encrypted (using SSL). Both had ‘Fast” data compression enabled. The SMB and AFP connections were standard, un-encrypted connections. Preservation of extended attributes was enabled for all tests. It’s worth noting that only the ChronoAgent synchronizations were able to truly preserve ownership and permissions of the synchronized files. Both the SMB and AFP file sharing connections are incapable of maintaining ownership/permissions fidelity.
Other than the differences in hardware configuration and connectivity methods mentioned above, all other aspects of these synchronizations were identical to each other. Each test was run three times and an average elapsed time was calculated, rounded up to the next second.
THE RESULTS
| ChronoAgent | ChronoAgent w/ Encryption | SMB File Sharing | AFP File Sharing | |
|---|---|---|---|---|
Initial Synchronization | 11:38 | 14:24 | 44:49 | 17:06 |
Cached Rescan | :12 | :13 | 2:05 | 1:04 |
Light Change Set | :20 | :22 | 3:24 | 1:07 |
Medium Change Set | :41 | :45 | 4:42 | 1:32 |
Heavy Change Set | 1:11 | 1:18 | 6:25 | 2:10 |
Full Deletion | 2:01 | 2:16 | 14:50 | 4:05 |
All times are in minutes:seconds. Smaller values are better. | ||||
ABOUT THE TESTS
Initial Synchronization
The initial synchronization is exactly what the name implies – the first run of the synchronization that backs up all 39,000 files/folders to an empty folder on the remote computer. This is generally the longest synchronization that users will run since everything must be copied. The disk cache was purged prior to each test to eliminate any benefits that file system caching may provide.
Cached Rescan
The cached rescan is an immediate re-invocation of the synchronization after the initial synchronization is complete. Since no files were modified in between runs, there are no files copied. It is purely a scan of both the source and destination file systems, looking for changes that don’t exist. Because it is run immediately after the initial synchronization, file system caching is providing a benefit to both the source and destination. Thus the result represents the fastest possible scan time that can realistically be achieved.
This is not a very real-world test because a fair amount of time and file system activity will typically occur in between synchronizations. It does provide useful information, however, if you plan to frequently schedule synchronizations (e.g. every five minutes) since you do not want to choose a scheduling interval that cannot be realistically attained.
Light Change Set
The light change set represents a typical synchronization after a very light amount of changes have been performed. It simulates casual system use in between synchronizations. Specifically, 129 files are modified representing 21.2 MB of data. The disk cache was purged before the synchronization was performed. This eliminates any benefits that file system caching may provide.
Medium Change Set
The medium change set represents a typical synchronization after a medium amount of changes have been performed. It simulates moderate system use in between synchronizations whereby work has been performed but not a particularly heavy amount. Specifically, 887 files are modified representing 134 MB of data. The disk cache was purged before the synchronization was performed. This eliminates any benefits that file system caching may provide.
Heavy Change Set
The heavy change set represents a typical synchronization after a heavy amount of changes have been performed. It simulates extensive system use in between synchronizations whereby an intense amount of work has been performed. Specifically, 2183 files are modified representing 370.2 MB of data. The disk cache was purged before the synchronization was performed. This eliminates any benefits that file system caching may provide.
Full Deletion
The full deletion is a complete, immediate deletion of all 39,000 files and folders on the destination target. The disk cache was purged before the synchronization was performed. This eliminates any benefits that file system caching may provide. Mass deletion is not a task that you would normally perform in a real-world synchronization. However, deletions become a factor when the ’Synchronize deletions’ setting is enabled. This test is a good measure of what kind of overhead to expect when mass deletions (e.g. caches and deleted junk mail messages) are part of a synchronization.
LARGE FILES BENCHMARK
This test synchronizes a small number of very large files to determine what kind of bandwidth can be achieved using a particular connection method. There are only five files in the data set but they represent a total of 29 GB worth of data.
THE RESULTS
| ChronoAgent | ChronoAgent w/ encryption | SMB file sharing | AFP file sharing | |
|---|---|---|---|---|
Initial Synchronization | 12:49 | 14:22 | 13:01 | 13:00 |
All times are in minutes:seconds. Smaller values are better. | ||||
ABOUT THE TEST
Initial Synchronization
The initial synchronization is exactly what the name implies – the first run of the synchronization that backs up all five files (29 GB of data) to an empty folder on the remote, destination computer. The disk cache was purged prior to each test to eliminate any benefits that file system caching may provide.
The results of this test call attention to the fallacy of using throughput as your sole benchmark indictor. All three connection methods have clearly reached the maximum throughput that the underlaying hardware will allow.
With the exception of the SSL encrypted transfer, the results are all comparable to each other. Simply looking at these numbers alone would lead you to believe that there was no clear advantage to any of these (non-SSL) connection methods. Looking at the results of the ‘Home Documents Benchmark’, however, you can clearly see that isn’t the case. The reason is simple: the overhead involved in creating a file, opening it for writing and closing it after the data is written is oftentimes much greater than transferring the contents of the file.
Simply put, one-thousand 1K files will copy MUCH slower than a single, 1000K file. Not to mention the fact that scanning a file system for change introduces an additional overhead that cannot be measured via throughput. This is where ChronoAgent achieves its greatest performance advantage because it is designed to perform the exact operations that ChronoSync needs to perform, and it will do so very efficiently.
REVISION HISTORY
May-14-2014 – Created.