Compression opt-out, performance killer

[Zaczero]

Most frameworks provide response compression as an opt-in. ConnectRPC-Python does not, and there is no easy way to opt out, which conflicts with my compression proxy. Adding to the issue, negotiate_compression is inefficient. It picks the first supported compression instead of the best one. For example, Google Chrome sends gzip, deflate, br, zstd where the ideal order of preference would be: zstd→br→gzip→deflate. ConnectRPC-Python picks gzip. And it uses the default settings, a compression level of 9 (https://docs.python.org/3/library/gzip.html#gzip.compress). This is a performance killer.

My feedback is that while ConnectRPC is an amazing piece of software, the compression layer is bad and it should be reworked or thrown away as it hurts more than it helps. I'm saying this because I've been solving very similar problems at https://github.com/Zaczero/pkgs/tree/main/starlette-compress (feel free to copy any piece of code you want; it's 0BSD).

My current workaround is to drop the Accept-Encoding header and compress when Content-Encoding is "identity". I may be open to contributing to connect-python if you point me in the right direction (if you have one), so I can understand what parts you are open to improving. I may find some additional things that need changing.

[anuraaga]

Hi @Zaczero - the connect ecosystem defaults to gzip compression, for example in connect-go so we won't be able to change that. But it definitely needs to be configurable - we have supported accept_compressions on the client side but not a similar knob on the server which IIUC is what you need, I sent #98 for that.

The gzip compression level definitely looks wrong, I sent #97 to improve that - thanks for letting us know.

Adding to the issue, negotiate_compression is inefficient. It picks the first supported compression instead of the best one.

This is also specified by the connect protocol itself, to treat the accept-encoding list as an ordered list of preference so we won't be able to change that. I believe this also aligns with gRPC's behavior. I understand that many servers like Envoy, etc, do allow the server to pick an appropriate compression when all have the same q - I think compatibility concerns may make it challenging but if you are interested, you may want to file an issue for the protocol repo on adding support for server-guided compression negotiation.

Note that supporting custom Compression implementations has always been a long term goal and not implemented yet as we worked towards feature parity. Now though it's probably a good time to look at that - let me know if the above fix to the default compression levels to align with Go isn't enough and you would need to specify a Compression with a custom level.

[Zaczero]

I did so: connectrpc/connectrpc.com#319

I'm now asking myself whether I misunderstood the idea of connectrpc. Isn't it meant to expose grpc-like services to HTTP? And to be consumed by the browsers? The existing spec design seems like it is made for cases where both the client and the server are primarily custom, non-standard software. It uses standard headers and assigns them new meaning. I'm very new to this project but I already like it a lot.

[anuraaga]

I think the initial announcement blog for connect-go might be the best to get background on connectrpc as a whole

https://buf.build/blog/connect-a-better-grpc

The standout point that relates to this discussion is probably

The Connect protocol is a simple, POST-only protocol that works over HTTP/1.1 or HTTP/2. It takes the best portions of gRPC and gRPC-Web, including streaming, and packages them into a protocol that works equally well in browsers, monoliths, and microservices. The Connect protocol is what we think the gRPC Protocol should be.

I would say one big driving motivation was to unify the RPC protocol for both internal RPC and external usage from a browser, but it's not necessarily to make RPC "web-like". There were some decisions while doing this, like taking advantage of HTTP content encoding to make compression easier to do on browser, but also to give a connect-specific definition for handling of accept-encoding. Note that there is no RFC defining how servers should pick from equal-value accept encodings - very strictly speaking, picking from first-to-last isn't necessarily invalid, nor would just picking randomly AFAICT. Whether it's the most user-friendly or best idea, it's hard to say now, but it's what we've got.

Note, I didn't develop connect, just worked on connect-python which is relatively new, so the above is just my analysis / interpretation as a long-time user and now maintainer. Hopefully it's helpful background.

[Zaczero]

Thank you very much! Are you open to contributions without prior discussion if they do not change the public API behavior?

[anuraaga]

Sure I personally have no problem with that - just I can't guarantee a change can be accepted if we find some issue such as an incompatibility with the connect ecosystem. So if you're open to that, then always happy for the help, or otherwise feel free to open a discussion or issue in advance if you feel it's worth confirming something first.

[Zaczero]

Okay. I'll do a general look around after the compression changes are merged and after I'm done with my own stuff to see what to help with. I plan on using connect-python more and I want it to be the best. :)