Conditional compression

[glenjamin]

Use case(s) - what problem will this feature solve?

I've been experimenting with enabling compression, after discovering that it wasn't enabled by default.

While building up some automated tests, I was using the health package for my testing.

Notably, the response format for the Check RPC is extremely small
https://github.com/grpc/grpc-proto/blob/23f5b568eefcb876e6ebc3b01725f1f20cff999e/grpc/health/v1/health.proto#L33-L41

As it stands, a Server can opt-in to compression by calling grpc.SetSendCompressor in an interceptor or a handler, or compression will be reflected against whatever encoding the client used.

However, there is no way that I can see to make the compression consider the size of the encoded data before making a compression decision. Although the Compressor is an interface that could decide not to modify the body, the grpc-encoding header is always set to the name of the compressor.

This is only likely to make a difference when there are a large number of small or high-entropy responses, but that's probably a fairly common scenario across RPCs found in the wild?

Proposed Solution

Perhaps a way for the Compressor interface to signal that it's opting out? A simple backwards-compatible change should be to allow Compress(w io.Writer) (io.WriteCloser, error) to return a nil for the WriteCloser.

From what I can see from the compress and recvAndDecompress functions, there appears to be an additional hdr that has a bit indicating whether the payload was actually compressed or not - regardless of what the grpc-encoding header says. If the payload isn't being encoded it seems like it should avoid setting the header, but it looks like it would work fine without removing the header.

Alternatives Considered

If the Server RPC implementation knows its payload does not compress well then it could explicitly call grpc.SetSendCompressor("identity"), but this seems like it would be annoying to have to scatter everywhere.

Additional Context

Not that I could think of

[arjan-bal]

Hi @glenjamin, you're correct that the gRPC protocol supports deciding whether to compress each message independently.

The request headers specify the compression algorithm via the grpc-encoding header. Each Length-Prefixed-Message has its own Compressed-Flag:

• If the Compressed-Flag is 1 (set), the Message data is compressed using the algorithm specified by the grpc-encoding header.
• If the Compressed-Flag is 0 (unset), the Message data is uncompressed, regardless of what the header says.

It looks like the existing gRPC Go APIs don't seem to expose this per-message control. I'm checking how other gRPC implementations (like C++ and Java) use the Compressed-Flag to check for consistency and precedent.

[arjan-bal]

After asking the team, I found that Java and C++ allow the client to disable compression using the following APIs:

• Java: Using the ClientCallStreamObserver.setMessageCompression method.
• C++: Using no_compression flag in writeOptions passed to the Write method.

To be consistent with C++ and Java, I think gRPC Go should provide this control on the Stream interface instead of determining the value solely based on the message size. I'm not sure about the best way to do this in a backward compatible way.

@easwars @dfawley would like to get your thoughts on this.

[glenjamin]

Thanks for the response

I tried to have a search for examples of people implementing some form of middleware-based (ie. not endpoint-specific) conditional compression using those mechanisms, but I couldn't seem to find anything.

I did find this though, which appears to suggest that the C++ code does have some internal heuristics where it knows it should skip compression:
grpc/grpc#22494

[dfawley]

Yes, ideally there would be direct per-message control. Any knobs for automatically deciding whether to use compression would probably want to be agreed upon cross-language.

It is pretty straightforward to add a new method (e.g. SendMsgCompressed/Uncompressed) that can be optionally implemented by a ClientStream (and ServerStream) returned from NewStream. But the problem is that interceptors return the real ClientStream, and there's no way to have a fallback implementation for this.

One option would be to add a grpc function like grpc.SetHeader that you'd call and pass the stream's context to, and it would cause the next message (or all subsequent messages?) to be compressed/not-compressed. This wouldn't be interceptable without an approach similar to ServerTransportStream, but that's probably fine, at least for now.

I'm not sure if there are any other options. Automatically doing it based on message size would be much nicer from an API perspective.

[dfawley]

One option would be to add a grpc function like grpc.SetHeader that you'd call and pass the stream's context to, and it would cause the next message (or all subsequent messages?) to be compressed/not-compressed. This wouldn't be interceptable without an approach similar to ServerTransportStream, but that's probably fine, at least for now.

Looks like for Java it toggles all subsequent messages on the streams:

https://grpc.github.io/grpc-java/javadoc/io/grpc/ClientCall.html#setMessageCompression%28boolean%29

That seems pretty good, so, fleshed out more, I think it would look like this:

package grpc

// SetMessageCompression enables or disables per-message compression on a stream if a
// compressor is specified for the stream (e.g. using UseCompressor or SetSendCompressor)
// and if the encoding type is supported by the receiver. By default, message compression
// is enabled, but is a no-op if compression is not enabled on the stream.
func SetMessageCompression(ctx context.Context, enable bool) {}

I also noticed what I believe is a bug. If the client sends a request with a particular encoding, then grpc-go servers will, by default, respond with that same encoding, and I believe it does that even if the client does not include that compressor in its accept-encoding header.

[glenjamin]

I believe you can get roughly that behaviour at the moment by calling grpc.SetSendCompressor("identity") within a handler or an interceptor.

The main drawback I can see of that approach is that you only have access to the msg at that point, not the encoded payload.

Although perhaps that's sufficient, as proto.Size() could be a reasonable way for user-land code to decide whether to enable or disable compression, and specific proto.Message types that were known to compress poorly could also be detected at that level

[dfawley]

I believe you can get roughly that behaviour at the moment by calling grpc.SetSendCompressor("identity") within a handler or an interceptor.

SetSendCompressor does not allow you to toggle it per message, only per stream (from https://pkg.go.dev/google.golang.org/grpc#SetSendCompressor):

It must not be called after any event that causes headers to be sent

It also only works on the server, not the client.