Okay, apologies for the self-replies, but I've got it working with an
interceptor to turn it on explicitly:
public static ServerServiceDefinition createWithCompressionEnabled() {
return ServerInterceptors.intercept(new MyServer(), new
ServerInterceptor() {
@Override
public <ReqT, RespT> Listener<ReqT> interceptCall(ServerCall<ReqT,
RespT> call, Metadata headers, ServerCallHandler<ReqT, RespT> next) {
call.setCompression("gzip");
return next.startCall(call, headers);
}
});
}
This cut my ~5mb response to ~500kb (kudos to `nethogs -v 3` to watch
cumulative process network traffic), which exactly matches the client-sent
compression with essentially the same payload.
I naively still think it'd be cool/desirable for the server to
automatically match the client's compression, but IANAE. :-)
Thanks!
- Stephen
On Sun, Aug 21, 2016 at 8:47 AM Stephen Haberman <[email protected]>
wrote:
> Hi,
>
> I've verified that ServerCallImpl has compressor=null. There is a
> setCompression method, but AFAICT no one calls it, and it's not immediately
> clear how I should go about calling it in my user code.
>
> Naively, I'm wondering why somewhere around here:
>
>
> https://github.com/grpc/grpc-java/blob/master/core/src/main/java/io/grpc/internal/ServerCallImpl.java#L85
>
> When we recognize the client has sent us a compressed request, that we
> don't also assume they can handle/desire a compressed response, and just
> set the compressor to the matching encoding.
>
> Then users could still call serverCall.setCompression(...) to change that
> (however you do that), but using the same encoding in the response as the
> request seems like a more reasonable/less surprising default?
>
> Thanks!
>
> - Stephen
>
>
>
>
>
> On Sat, Aug 20, 2016 at 2:48 PM Stephen Haberman <
> [email protected]> wrote:
>
>> Hi,
>>
>> I'm using grpc-java 1.0.0.pre2, and it seems like server-side/response
>> compression may not be working.
>>
>> I'm making a synchronous call from a client, and sending ~40k objects,
>> e.g. FooRequest.newBuilder().addAllPaths(...40k...).build().
>>
>> The server then collects it's own 40k objects (again paths) and returns
>> it as the response to the client's request, e.g.
>>
>>
>> responseObserver.onNext(FooResponse.newBuilder().addAllPaths(...40k...).build());
>> responseObserver.onCompleted();
>>
>> These 40k objects are all basically file paths + a long modification
>> time, and there will be a lot of duplication in the paths (e.g. /home/.../
>> in all of them), so compression should really help with the payload size,
>> so I'm turning on gzip:
>>
>> Channel c = NettyChannelBuilder.forAddress(host,
>> port).negotiationType(NegotiationType.PLAINTEXT).maxMessageSize(maxMessageSize).build();
>> MirrorStub stub = MirrorGrpc.newStub(c).withCompression("gzip");
>>
>> However, nethogs shows that the client request is ~400kb, but the
>> server's response is ~5mb. Even though in theory, the request and response
>> should be exactly the same size (the response is responding with
>> essentially the same input the client sent).
>>
>> Basically it looks like the server is not responding with a gzip'd
>> response.
>>
>> I'm not registering any decompression factory with the server, but AFAICT
>> gzip is one of the defaults:
>>
>> ServerImpl rpc =
>> NettyServerBuilder.forPort(port).maxMessageSize(maxMessageSize).addService(new
>> MirrorServer()).build();
>>
>> Before I go digging, is this expected? That the server's response would
>> not be compressed?
>>
>> Thanks,
>> Stephen
>>
>>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/CANnRKuWdze9SenN9qmMHi8LHaiXde2kH6eMnDDDD1c84hR9Rcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
