Broccoli: Syncing faster by syncing less (2020)

https://dropbox.tech/infrastructure/-broccoli--syncing-faster-by-syncing-less

by KubikPixel • 5 years ago

66 20 5 years ago

jsnell• 5 years ago

Discussion from a year ago: https://news.ycombinator.com/item?id=24052002

donatj• 5 years ago

Rolling out the above changes went relatively smoothly until one of the curious engineers on our network team found that compression was actually a bottleneck on high bandwidth connections

Back in the early-to-mid-aughts there was a push to start gzip-ing server responses.

It was my general experience at the time that this actually often made the browsing experience worse. Whereas without compression the page would begin to render as the html began to trickle in (very slow internet back then), when compressed you had to wait for the entire document to download and be decomposed first.

Uncompressed you could often decide if the page was worth waiting for entirely before it finished downloading.

gampu• 5 years ago

Not sure how compression was a bottleneck on the high bandwidth connections? I understand @donatj's comments about having to wait for the entire file to be downloaded before rendering, but that would be a user experience issue, not sure how the network team sees it as a bottleneck on the network?

tshaddox• 5 years ago

I assume they meant that the network could move bytes faster than the CPU could compress them.

kevinday• 5 years ago

HTTP requires that the length of the content be sent before the content, so that pipelined connections know where the data ends and the next headers start. If you're sending a file directly off disk you know the size before you've even looked at the data so there's no delay. If you're running everything through gzip, you have to wait to compress the entire file before you know the output length, so the critical "time to first byte" metric could get much worse. There are similar issues with dynamic content (CGI scripts, PHP, etc) where both the server and browser would end up buffering large amounts of content before compressing/decompressing them, which also affected perceptual speed. If the connection bandwidth was high enough, skipping all of this and just sending the uncompressed file would appear faster to the user, despite transferring more.

This was later improved with things like chunked encoding and caching the compressed output on the server side, but they came later and weren't always supported or desirable.

davidmurdoch• 5 years ago

Gzip is streamable (windowed), so perhaps it was the extra CPU cycles that caused the slow down, misconfigured gzip, or just incomplete gzip implementations?

gigatexal• 5 years ago

As long as this makes the client on Mac use less resources than a fork bomb I’m all for it.

Eric_WVGG• 5 years ago

It doesn’t, the client code is still a dumpster file.

Give Mistrael a look. Anecdotally ~7x less RAM, ~10x less disk space. https://maestral.app

rkagerer• 5 years ago

Is there anything like this for Windows?

QuadrupleA• 5 years ago

All this talk of efficiency, yet the Dropbox windows client is such a bloated multi-process memory hog of a mess that I ended up uninstalling it and rigging my own sync with a command line tool (dbxcli), with about 1000x less resource usage.

For all this attention to saving their server's resources they sure don't seem to care much about wasting their customers'.

howdydoo• 5 years ago

This is classic.

"We spent $x million developing a compression algorithm in Rust to slightly speed up a background process in our bloated Electron app!"

hedgehog• 5 years ago

The Electron app wouldn't be an issue if it didn't churn away uselessly even when Dropbox is in the background. The company doesn't care though, their advice was to open a topic in the support forum, to which their response is "This idea will need some more support before we can share it with the team." You can lead a horse to water.

FractalHQ• 5 years ago

With so many Rust engineers, they could get rid of all that Electron bloat with the Rust-based electron alternative, Tauri.

davidjade• 5 years ago

I really wish this idea had become more widespread. Microsoft Research published this 15 years ago. It shipped as part of windows but the paper describes it in enough detail to implement it I think. I got it running years ago and it seemed to work really well.

https://www.microsoft.com/en-us/research/wp-content/uploads/...

irq-1• 5 years ago

Interesting. Looks like Windows does use it the Distributed File System Replication (DFSR) service.

https://docs.microsoft.com/en-us/previous-versions/windows/d...

teleforce• 5 years ago

Open source implementation of DRC:

https://github.com/zhi3385/openrdc

jeffybefffy519• 5 years ago

Why cant you guys enable multiple account sign ins from the one dropbox client. So annoying.

ChrisArchitect• 5 years ago

What is new here from the conversation a year ago when this was new.

https://news.ycombinator.com/item?id=24052002

rcarmo• 5 years ago

And yet the Mac client still wakes up whenever I touch files outside my Dropbox folder, and has become a monstrosity full of “UX” I never use (so I switched to other things, and most of my friends to https://github.com/SamSchott/maestral).

Broccoli: Syncing faster by syncing less (2020)

Related Stories