Tracking Issue for Codec, Compressor, CompressionRegistry being Experimental.

[carl-mastrangelo]

They may exist, even independent of turning off compression for public release.

[carl-mastrangelo]

Specific usages:

• CallOptions.getCompressor
• CallOptions.withCompression
• Codec
• Compressor
• CompressorRegistry
• Decompressor
• DecompressorRegistry
• DecompressorRegistry.getAdvertisedMessageEncodings
• ManagedChannelBuilder.decompressorRegistry
• ManagedChannelBuilder.compressorRegistry
• PartialForwaringServerCall.setCompression
• ServerBuilder.compressionRegistry
• ServerBuilder.decompressionRegistry
• ServerCall.setCompression
• AbstractStub.withCompression

[louiscryan]

Primary deficiency is that what we really want is to rely on negotiation of the allowed compressors to control what is permitted and then have a simple API to control high/med/low (for some definition of those concepts).

We can't use negotiation for the first call to a service as negotiation may not have occurred so we will always need an API to allow client to assert a subset of supported compressions types for the first call.
E.g.

CallOptions.assumeInitialAllowedCompressors(....)

[louiscryan]

Leaving experimental for 1.0 unless significant effort can be found to address the known issues and resolve this consistently across the other impls

[larry-safran]

Stabilize the following by removing @ExperimentalApi - Larry to do
CallOptions.withCompression
CallOptions.getCompressor
ServerCall.setCompression - make clear it is for sending
ServerCall. setMessageCompression
AbstractStub.withCompression - update javadoc to stop implying have to call decompressionRegistry

[0001vrn]

Hi @larry-safran @ejona86
Is this feature stabilised now? if yes, which version should we use? any examples? any benchmarks?
Also, do we have any success story for lib/team using this compression in production workloads?
Thanks

[ejona86]

The built-in compression has been in reasonably wide use since 1.0. I discourage implementing custom compression methods (so avoid the registries).

[eitanbn]

We have got bad performance results when using gzip compression

• The overall communication speed in our web application' is slightly slower
• The memory consumption of the agent running gRPC server increased from 2 GB to 3GB

We are using the code we have found in the internet as follows;

Server Side

server = ServerBuilder.forPort(port)
			// Set GZIP compression
			.intercept(
						 new ServerInterceptor() {
						 @Override
						 public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(ServerCall<ReqT, RespT> call, Metadata headers,
						                                                               ServerCallHandler<ReqT, RespT> next) {
						     call.setCompression("gzip");
						     return next.startCall(call, headers);
						 }
				})
			.addService(new OurGrpcServiceImpl())
			.build();

Client Side

    ourStub = OurtServiceGrpc.newStub(channel).withCompression("gzip");

or

    ourtBlockingStub = OurServiceGrpc.newBlockingStub(channel).withCompression("gzip");

Can you please advice?

Thanks,
Eitan

[ejona86]

Enabling compression will consume more memory and CPU. But it is a trade-off, because it reduces network costs and in some networks decreases latency. Use it when the trade-off is worth it to you.