Thank you Ishan and Mark for chiming in. >From the feedback I received so far it looks like there is very little gain to be had enabling compression. I tried running some tests locally and this fits, I don't see any gains, whatever you might save on transfer time, you waste on compression.
Together with the question of "is compression worth it", I also had the question of "why does http2 client not support this". it looks like one informs the other, if compression is not useful, then it makes sense to not expose it as a flag on the client - at least that is how I am reading the current state. And to answer my own question, it looks like the http2 client might set the ACCEPT_ENCODING to null because the jetty client will auto-add the 'accept-encoding:gzip' header by default [0] - I am reading this as someone caught this and manually disabled this auto gzip behavior by setting the header to null. best, alex [0] https://github.com/eclipse/jetty.project/issues/7681 On Fri, Apr 21, 2023 at 7:52 PM Mark Miller <markrmil...@gmail.com> wrote: > If you are looking for performance, you probably want to do some tests to > verify you will get it. > > Most of the binary protocols seem to avoid compression beyond what Solrs > JavaBin does, which is very simple numerical compression, with the idea the > cost should be small enough to maintain a performance win. The guy that did > protobufs stopped doing even that in his latest project in the name of > performance. I think maybe that’s fixed size structures where you can > almost directly load native types from it though. > > My assumption is that it’s going to depend on the protocol and the typical > data going over that protocol whether it would make any sense or not, so > would have to test it out. >
