System.currentTimeMillis() is not ideal for measuring elapsed time.  It's meant 
for measure the current time.  Instead, try doing:


long startNanos = System.nanoTime();

// ... Do the RPC

long stopNanos = System.nanoTime();

tick("GrpcClient.Get", TimeUnit.NANOSECONDS.toMillis(stopNanos - startNanos));


As for the discrepancy, are you sure you don't have any exceptions being 
thrown?  If the call failed the time would not be recorded.  This is important 
for deadline exceeded calls, because they would make the average latency go way 
up.




On Thursday, November 29, 2018 at 1:24:20 PM UTC-8, Yee-Ning Cheng wrote:
>
> 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/1edc0fa9-05a1-4e4f-84cd-e07e59769a0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to