Tracking Issue for Codec, Compressor, CompressionRegistry being Experimental.  #1704

Activity

1. carl-mastrangelo

   assigned

   ejona86

   on Apr 21, 2016
2. carl-mastrangelo

   added this to the 1.0 milestone on Apr 21, 2016
3. hsaliak

   added

   P2

   on Apr 26, 2016
4. carl-mastrangelo

   changed the title [-]Codec, Compressor CompressionRegistry should be checked if they should still be experimental.[/-] [+]Tracking Issue for Codec, Compressor, CompressionRegistry being Experimental. [/+] on May 3, 2016
5. carl-mastrangelo commented on May 3, 2016

   

   carl-mastrangelo

   on May 3, 2016

   Last edited by carl-mastrangelo

   ContributorAuthor

   More actions

   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
6. louiscryan commented on May 23, 2016

   

   louiscryan

   on May 23, 2016

   Contributor

   More actions

   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(....)
7. louiscryan commented on May 23, 2016

   

   louiscryan

   on May 23, 2016

   Contributor

   More actions

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

   modified the milestones: 1.1, 1.0 on May 23, 2016
9. ejona86

   modified the milestones: Unscheduled, 1.1 on Aug 9, 2016
10. ejona86

    added

    experimental APIIssue tracks stabilizing an experimental APIIssue tracks stabilizing an experimental API

    on Aug 22, 2016
11. ejona86

    modified the milestone: Unscheduled on Aug 30, 2016
12. ejona86

    removed their assignment

    on Aug 30, 2016
13. larry-safran commented on Feb 15, 2023

    

    larry-safran

    on Feb 15, 2023

    Last edited by larry-safran

    Contributor

    More actions

    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
14. ejona86

    assigned

    larry-safran

    on Feb 15, 2023
15. 0001vrn commented on Mar 3, 2023

    

    0001vrn

    on Mar 3, 2023

    Last edited by 0001vrn

    More actions

    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
16. ejona86 commented on Mar 3, 2023

    

    ejona86

    on Mar 3, 2023

    Member

    More actions

    The built-in compression has been in reasonably wide use since 1.0. I discourage implementing custom compression methods (so avoid the registries).
17. eitanbn commented on Mar 5, 2023

    

    eitanbn

    on Mar 5, 2023

    Last edited by ejona86

    More actions

    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
18. ejona86 commented on Mar 6, 2023

    

    ejona86

    on Mar 6, 2023

    Member

    More actions

    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.
19. larry-safran

    added 2 commits that reference this issue on Mar 6, 2023

    api,stub:Stabilize part of compression agreed to in the stabilization…

    ...

    a792c7e

    api,stub:Stabilize part of compression agreed to in the stabilization…

    ...

    136665f