I also have a metric that surrounds the actual blocking call (I am using the
blocking stub in this case).
Long time = System.currentTimeMillis();
Userprofile.ReadResponse resp = blockingStub
.withDeadlineAfter(timeout, TimeUnit.MILLISECONDS)
.get(req.build());
tick("GrpcClient.Get", System.currentTimeMillis() - time);
The issue is that this metric (the one surrounding the blocking call) is
reporting a much lower latency (~100ms vs ~400ms). Why is there such a
discrepancy? And which one is correct?
I will look into the ClientStreamTracer to see what's there as well. Thanks!
On Thursday, November 29, 2018 at 3:57:31 PM UTC-5, Carl Mastrangelo wrote:
>
> That is one way. For more precise (but about as accurate) numbers,
> consider using a ClientStreamTracer, which you can set on the
> ManagedChannelBuilder. That has more fine-grained events about an RPC.
>
> On Wednesday, November 28, 2018 at 1:55:12 PM UTC-8, Yee-Ning Cheng wrote:
>>
>> I am trying to measure gRPC unary requests from a client.
>>
>> I have implemented an interceptor very similar to
>>
>>
>> https://github.com/grpc-ecosystem/java-grpc-prometheus/blob/master/src/main/java/me/dinowernli/grpc/prometheus/MonitoringClientCallListener.java
>>
>> I also have a metric surrounding the client call and this time is much
>> lower than the time measured from the interceptor.
>>
>> Is the above interceptor implementation the correct way to measure each
>> unary request from the client?
>>
>> Thanks
>>
>
--
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 grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/a74bd564-5fa4-4dc9-9f1c-8b238dbdcf8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
