How to disable server-side compression via configuration?

[gm42]

I have seen from https://github.com/grpc/grpc-go/blob/master/Documentation/compression.md that the capability to configure server-side decompressor/compressort support has been marked as legacy.

Going forward, is there a way to disable server-side gRPC compression support, for example via configuration?

Something like:

if supportCompression {
    grpcServer.EnableRequestDecompression = true
    grpcServer.EnableResponseCompression = true
}

[dfawley]

Can you explain a bit why you want to disable compression support? Also, do you want to be able to control this per-gRPC.Server instance or per-service registered / per-method?

[gm42]

Can you explain a bit why you want to disable compression support?

Compression/decompression has an impact on CPU usage, and this is particularly relevant for deployments on Kubernetes (slightly related semi-random blog post: https://medium.com/omio-engineering/cpu-limits-and-aggressive-throttling-in-kubernetes-c5b20bd8a718).
Additionally, functionality can be abused, either accidentally or purposefully, to cause DoS (both on memory and CPU side, think about the request limits for Kubernetes pods).

The general use-case is that if you are modeling the CPU/memory usage of a service the presence of compression/decompression introduces great variability there; a slightly more advanced scenario is where you would allow a proxy or service mesh to use dedicated hardware functionality to handle compression/decompression rather than having the Go services do it themselves. The reasoning is similar as of why we have nowadays TLS termination outside of the services.

Also, do you want to be able to control this per-gRPC.Server instance or per-service registered / per-method?

I didn't check the current implementation but I assume that some form of negotiation is happening (and client is not "blindly" sending compressed requests / accepting compressed responses); I was thinking of gRPC.Server-level but perhaps there could be other use-cases where a finer granularity would be beneficial (even just for some blue/green deployment strategy). I would probably pursue the feature only at gRPC.Server level for the lack of better use cases.

[dfawley]

Thanks for the additional information.

• Decompression: I don't think we would support disabling decompression via a boolean flag like this. What we may consider allowing is a way to specify a compressor registry per-server/client instead of globally, which you could use to just not register any compressors. If the client attempted to use compression, that would cause RPC errors (though the client should be using the grpc-accept-encoding header to avoid this; see Missing support for grpc-accept-encoding #2786).

• Compression: right now we use the same compression scheme as the client used for transmission for historical reasons. We should change things so we use the grpc-accept-encoding header instead. This should also be covered by Missing support for grpc-accept-encoding #2786.

Unless you disagree, in which case feel free to comment, let's merge this issue with #2786.