Large amount of download traffic even with no updates

I’m on the road a lot so I monitor how much network traffic my apps are using. I’ve noticed that odrive generates a lot of download traffic even when the connected source has very few changes (maybe one or two files modified). I essentially haven’t done anything on my Google Drive over this past weekend, but odrive has downloaded 1.7 GB of information in 4 days. This cannot be right, can it? Little Snitch tells me it’s all calls to googleapis.com… I use a mifi with usage limits so this is kind of a big deal for me.

Thanks for any insight anyone can give.

Hi @ianjbuss,
Can you tell me what storage you have linked and how large of a structure you have exposed in odrive?

odrive will perform periodic full scans of the remote storage, which can create a good amount of metadata that is sent back to odrive if there are a lot of folders to scan. odrive will also frequently ask for remote storage changes, which are very small calls if nothing has changed.

Does the network usage show any significant spikes, or is it a low quantity, but with regularity?

Hi @Tony,

Thanks for your reply. I have the following linked:

Google (work) - 3345 objects, approx 10GB used
Google (mine) - 73 objects, approx 4GB used
Box - 23 objects

Together, googleapis.com has now used 2.2 GB over 4 days, box.com 222 kB, odrive.com 954 kB.

I will capture some traffic for a while to get a profile but I notice odrive kicking in every couple of minutes. I currently have auto-sync off.

So, unscientific hunch from packet capture shows bursts every 10-30 seconds or so. The top 5 IPs (all Google registered) had 19 MB, 10 MB, 9 MB, 9 MB, 7 MB of download traffic in a roughly 30 min window. This seems unusually high to me.

Thanks @ianjbuss,
Yeah that does seem higher than expected. Can you send a diagnostic report after odrive has seemed to be idle for a while? I want to take a look to see if there is anything cycling.

odrive will ask Google for changes every 30 seconds, or so. You can expect to see requests to Google for the 2 accounts you have linked, but those requests should be really small if there have been no changes since the last time.

@Tony I’ll collect that at some point today. How can I PM you the file?

Hi @ianjbuss,
The diagnostic will be sent to us once you send it via the odrive menu (“Send diagnostics”). Just let me know when you send it so I can go looking for it.

@Tony I re-enabled odrive and let it run for 30 mins (I turned it off to stop the traffic) and I’ve sent the diagnostic bundle. It downloaded 45 MB or so in just that time. Thanks

Hi @ianjbuss,
I took a look at your diagnostic and ran a few tests. I believe the bulk of the data is just from Google Drive’s metadata returns, which are actually fairly large, per object, compared to some other services (about 4-5KB per object). They have a lot of metadata they track.

It looks like you have close to 1000 folders in one of your Google Drive accounts, which means at least 2x that in metadata object returns when odrive does a full scan, just for the folder objects. Add in the file objects, and the total data returned can start to add up to tens of MB pretty quick.

We may be able to trim these returns down to reduce the object metadata payload significantly. I will look into it.

@Tony, thanks , that’s interesting. Good to know and agrees with what I can see here from within my larger drive account:

$ find . -type d | wc -l
991

I initially did a full sync, I’m wondering if the metadata returned on un-synced objects, i.e. “*.cloudf” is the same. Maybe I should auto un-sync much of the drive contents?

Hi @ianjbuss,
I have a change going through QA right now that will cut down on the metadata payloads. I will update here once we have a release.

Hi @ianjbuss,
This change is out now and available for download: https://docs.odrive.com/v1.0/docs/odrive-usage-guide#section--install-desktop-sync-

Hi @Tony. I downloaded the new version a few days ago and the traffic has been massively reduced. Thanks!

1 Like

Great! Thanks for confirming @ianjbuss