Refresh causes download of full snap file instead of delta

@mvo I’ve tested this on a low-end single-core ARM cortex-a7 device that we should consider our “worst case” using xdelta3 directly.

  1. core 4020 -> 4114 (normal scenario ~8 seconds):
alextnewman@ricardo:~/delta-test$ ls -lh core_4*
-rw-r--r-- 1 alextnewman alextnewman 69M Mar  1 22:03 core_4020.snap
-rw-rw-r-- 1 alextnewman alextnewman 21M Mar  1 22:05 core_4020_to_4114.vcdiff
-rw-r--r-- 1 alextnewman alextnewman 69M Mar  1 21:47 core_4114.snap
alextnewman@ricardo:~/delta-test$ time xdelta3 -d -s core_4020.snap core_4020_to_4114.vcdiff core_out-2.snap

real	0m8.008s
user	0m0.790s
sys	0m2.710s
  1. core 953 -> 4114 (huge diff ~9 seconds):
alextnewman@ricardo:~/delta-test$ ls -lh core_*
-rw-r--r-- 1 alextnewman alextnewman 69M Mar  1 21:47 core_4114.snap
-rw-r--r-- 1 alextnewman alextnewman 65M Mar  1 21:37 core_953.snap
-rw-rw-r-- 1 alextnewman alextnewman 53M Mar  1 21:52 core_953_to_4114.vcdiff
alextnewman@ricardo:~/delta-test$ time xdelta3 -d -s core_953.snap core_953_to_4114.vcdiff core_out.snap

real	0m9.162s
user	0m0.850s
sys	0m2.850s 
  1. rocketchat-server 1164 -> 1121 (normal diff, large snap ~21.3 seconds):
alextnewman@ricardo:~/delta-test$ ls -lh rocketchat*
-rw-r--r-- 1 alextnewman alextnewman 155M Mar  1 21:39 rocketchat-server_1164.snap
-rw-r--r-- 1 alextnewman alextnewman 162M Feb 28 21:07 rocketchat-server_1211.snap
-rw-rw-r-- 1 alextnewman alextnewman  47M Mar  1 21:46 rocketchat_1164_to_1211.vcdiff
alextnewman@ricardo:~/delta-test$ time xdelta3 -d -s rocketchat-server_1164.snap rocketchat_1164_to_1211.vcdiff rocketchat-server-out.snap

real	0m21.386s
user	0m1.860s
sys	0m6.240s

Considering this device is our “worst case” for performance, it looks to me like we’re not spending nearly the time reconstructing deltas that we are hashing, so I’m inclined to say that the trade-off is well worth the bandwidth saved. On x86, meanwhile, the performance hit appears to be fairly negligible (and this is where most of our current stakeholders are). So, I’m going to recommend this be “on” by default with the possibility to manually disable for bandwidth-rich time-critical deployments.

3 Likes