I know I can check transfer stats to know how much data has been saved thanks to the compression, but there doesn’t seem to exist any reliable method to check how “all data” compression impacts device performance.
My question basically would be - how much of a performance impact can one expect to experience when compressing “all data” instead of “metadata only”? I’m talking about a situation, where multiple dynamic folders change often and there are constant transfers going on to multiple devices all the time.
Is the performance impact so insignificant that enabling it is worth it, e.g. on mobile devices that have to deal with data transfer limits? Alternatively, is it so insignificant that enabling it on older computers with CPUs like Core 2 Duo and such won’t cause any slowdowns?
I’ve been experimenting myself, but it is really difficult to tell or isolate the specific option when so much other stuff is happening in Syncthing at the same time .
I do sync quite a lot of plain text though, especially when it comes to the stuff that constantly changes . The heavier files are mostly static though.
Measure twice, cut once. Only you can see the impact in your setup. What bt90 observes is the reason it’s not enabled by default. Is bandwidth more scarce than cpu? Then I guess enable.
It kind of is, because at least some devices are located on a very slow network (in particular regarding its upload speed). At the same time, I’d prefer not to peg the CPUs by enabling the compression, especially as some of the involved devices are old desktops and mobile phones.
In other words, if the compression overhead is just a few percent, then yeah, I’ve got no qualms about enabling it, but if the overhead is 20% or more, then I’d think twice about enabling it, or maybe enable it only selectively.
Could anyone suggest a reliable way to benchmark such an overhead though? I can do the testing either either on Windows or Linux, if required.
I think compression is LZ4, so you could maybe ballpark some numbers by testing LZ4 performance? Don’t know if that yields anything useful though, or how to benchmark the LZ4 implementation.
The linked implementation claims to be a fork of https://github.com/lz4/lz4, which has available binaries to download. From a quick look, it seems they support a few switches to benchmark the actual compression algorithm.
Still, I don’t really think it will tell me anything conclusive regarding Syncthing’s compression performance. Even without benchmarking, I already know which devices will perform well and which ones will show poor numbers. The question remains how much of a performance hit they actually receive in real life, i.e. how much CPU is used with compression turned on and off, and also whether there is any significant time penalty for compressing the data.
Other than benchmarks of the raw performance of the compression algorithm itself, most of the impact will depend on the type of data involved plus the level of hardware acceleration.
.
. The heavier files are mostly static though.