Live data from Hacker News

Broccoli: Syncing faster by syncing less (2020)

dropbox.tech

1–10 of 25 posts

Re: Broccoli: Syncing faster by syncing less (2020)

#3
> 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.

Re: Broccoli: Syncing faster by syncing less (2020)

#5
post #3

> 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…

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?

Re: Broccoli: Syncing faster by syncing less (2020)

#6
post #3

> 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…

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

Re: Broccoli: Syncing faster by syncing less (2020)

#7
post #5
post #3

> 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…

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?

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

Re: Broccoli: Syncing faster by syncing less (2020)

#9

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

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

Post reply on HN