fected by the low execution efficiency of JavaScript in-
side web browsers. Even under simple (or says one-
shot) file editing workloads, WebRsync is slower than PC
client-based delta sync by 16–35 times, and most time
is spent at the client side for performing computation-
intensive chunk search and comparison operations.
2
This causes web browsers to frequently stagnate and
even hang (i.e., the browser never reacts to user actions).
Also, we find that the drawback of WebRsync cannot be
fundamentally addressed through native extension, par-
allelism, or client-side optimization (§4).
Driven by above observations, our first effort to-
wards practical web-based delta sync is to “reverse” the
WebRsync process by handing all chunk search and com-
parison operations over to the server side. This effort also
enables us to re-implement these computation-intensive
operations in efficient C code. The resulting solution
is named WebR2sync (Web-based Reverse rsync). It
significantly cuts the computation burden on the web
client, but brings considerable computation overhead to
the server side. To this end, we make two-fold additional
efforts to optimize the server-side computation overhead.
First, we exploit the locality of users’ file edits which
can help bypass most (up to ∼90%) chunk search op-
erations in real usage scenarios. Second, by leverag-
ing lightweight checksum algorithms, SipHash [20] and
Spooky [17] instead of MD5, we can reduce the com-
plexity of chunk comparison by ∼5 times. The final so-
lution is referred to as WebR2sync+, and we make the
source code of all our developed solutions publicly avail-
able at https://WebDeltaSync.github.io.
We evaluate the performance of WebR2sync+ using
a deployed benchmark system based on a Dropbox-like
system architecture. We show that WebR2sync+ out-
paces WebRsync by an order of magnitude, approaching
the performance of PC client-based rsync. Moreover,
WebR2sync+ is able to simultaneously support 6800–
8500 web clients’ delta sync using a standard VM server
instance under regular workloads
3
. Even under intensive
workloads, a standard VM instance with WebR2sync+
deployed can simultaneously support 740 web clients.
2 Delta Sync Support in State-of-the-Art
Cloud Storage Services
In this section, we present our qualitative study of delta
sync support in state-of-the-art cloud storage services.
The target services are selected for either their popularity
( Dropbox, Google Drive, Microsoft OneDrive, iCloud
Drive, and Box.com), or representativeness in terms of
2
In contrast, when a user downloads a file from the cloud with a
web browser, the client-side computation burden of delta sync is fairly
low and thus would not cause the web browser to stagnate or hang.
3
Detailed description of simple, regular, and intensive workloads
we use in this work is presented in §6.2.
Service PC Client Mobile App Web Browser
Dropbox Yes No No
Google Drive No No No
OneDrive No No No
iCloud Drive Yes No No
Box.com No No No
SugarSync Yes No No
Seafile [16] Yes No No
QuickSync [25] Yes Yes No
DeltaCFS [51] Yes Yes No
Table 1: Delta sync support in 9 cloud storage services.
techniques used (SugarSync, Seafile, QuickSync, and
DeltaCFS). For each service, we examined its delta sync
support with different access methods, using its latest-
version (as of April 2017) Windows PC client, Android
app, and Chrome web browser. The only exception oc-
curred to iCloud Drive for which we used its latest-
version MacOS client, iOS app, and Safari web browser.
To examine a specific service with a specific access
method, we first uploaded a 1-MB
4
highly-compressed
new file ( f ) to the cloud (so the resulting network traffic
would be slightly larger than 1 MB). Next, on the user
side, we appended a single byte to f to generate an up-
dated file f
0
. Afterwards, we synchronized f
0
from the
user to the cloud with the specific access method, and
meanwhile recorded the network traffic consumption. In
this way, we can reveal if delta sync is applied by measur-
ing the traffic consumption—if the traffic consumption
was larger than 1 MB, the service did not adopt delta
sync; otherwise (i.e., the traffic consumption was just
tens of KBs), the service had implemented delta sync.
Based on the examination results listed in Table 1, we
have the following observations. First, delta sync has
been widely adopted in the majority of PC clients of
cloud storage services. On the other hand, it has never
been used by the mobile apps of any popular cloud stor-
age services, though two academic services [25,51] have
implemented delta sync in their mobile apps and proved
the efficacy. In fact, as the battery capacity and en-
ergy efficiency of mobile apps grow constantly, we ex-
pect delta sync to be widely adopted by mobile apps in
the near future [36]. Finally, none of the studied cloud
storage services supports web-based delta sync, despite
web browsers constituting the most pervasive and OS-
independent method for accessing Internet services.
3 WebRsync: The First Endeavor
WebRsync is the first workable implementation of web-
based delta sync for cloud storage services. It is imple-
mented in JavaScript based on HTML5 File APIs [18]
and WebSocket. It follows the algorithm of rsync and
thus keeps the same behavior as PC client-based ap-
4
We also experiment with files much larger than 1 MB in size, i.e.,
10 MB and 100 MB, and got the same results.
156 16th USENIX Conference on File and Storage Technologies USENIX Association
