The purpose of this test is evaluate the performance of branches developed by Kai Risku running backups of a Evernote repository:
- Repository: an Evernote data folder, with ~3.47 Gb, of which the database (exb file) represents 3.38 Gb (97%).
- Storages - three local folders:
- one for the "Duplicacy official" compilation (DO)
- one for the "hash_window" compilation (HW)
- one for the "file_boundaries" compilation (FB)
- All storages with variable 1M chunks.
- Perform the full initial backup of the entire folder using the three jobs.
- Proceed with normal daily use for a few days, that is, add/edit some notes, representing a few kb of changes per day, and run a daily incremental backup.
- At the end, run the internal "optimize" command from Evernote to evaluate the impact.
- The repository and storage sizes were measured with Rclone (www.rclone.org).
prunecommand will be executed.
In the days with "normal usage" the total size of the storage was consistently smaller for the hash_window compilation.
With respect to the total number of chunks, the performance of the hash_windows compilation was similar to the "official" compilation, but the file boundaries branch presented a much different performance.
But when we evaluate the new daily chunks this difference is smaller, that is, the difference seems to be due to the initial generation of chunks.
Upload performance is aligned with new daily chunks:
Then, on the last day, when performing the "optimization" of the database, the "disaster" (in terms of storages sizes) happens:
Note that the upload is even bigger than the full initial backup:
And the same applies to new daily chunks:
But, the total chunks showed a completely different behavior:
By my understanding, although all the chunks were replaced in the 3 jobs, the file boundaries compilation generated less chunks this time.
In this test, as in Test 7, the hash window compilation showed a slightly better performance.
The Evernote database optimization command, which basically consists of a general reindexing, strongly impacted the results again. The backup is only feasible if the Duplicacy prune command is synchronized with the Evernote optimization command.
|Day||Repository size by Rclone||Repository increase (kb)|
|DO - storage size by Rclone||DO - storage increase||Revision||DO - all chunks||DO - new chunks||DO - uploaded||backup time - Complete (1M VAR)|
|HW - storage size by Rclone||HW - storage increase||Revision||HW - all chunks||HW - new chunks||HW - uploaded||backup time - DB (1M FIX)|
|FB - storage size by Rclone||FB - storage increase||Revision||FB - all chunks||FB - new chunks||FB - uploaded||backup time - DB (1M FIX)|