Size of gRPC completionqueue

[aksh...@umich.edu]

Hello,

I have a particular case where I'm interested in looking at the size of the completion queue at the server. I don't see a public API declared in "include/grpc++/impl/codegen/completion_queue.h".

Is there a way to access queue size from the asynchronous server?

Regards,

Akshitha

[Craig Tiller]

What do you mean by size?

The memory allocated when a CQ is instantiated?
The number of pending tags? The number of queued tags?

Can you tell me more about your use case: why is such a number interesting?

--
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+u...@googlegroups.com.
To post to this group, send email to grp...@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/ec8847f0-9b5f-4eeb-a7e6-82667e2bc740%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Akshitha Sriraman]

I'm working on an application that has a fan-out - load generator
communicates with the middle tier, which then communicates with leaf
nodes.
As a baseline, I would like to look at the throughput and end-to-end
latency associated with empty gRPC communications. In this specific
case, it happens to be a ping-ping-pong-pong (1 leaf node). I know
that the latency of a synchronous gRPC ping-pong is ~190 microseconds.
So, I should expect to see a ping-ping-pong-pong latency of ~380
microseconds. But, I want to look at the latency associated with
various load conditions.
I see from a closed loop test that such an "empty-packet"
communication system achieves a saturation throughput when there are
100K outstanding requests. This seems like a ridiculously high number
of outstanding requests. Also, I would expect 100K outstanding
requests to lower achieved throughput, since queuing delays must
dominate at this point. If the cost of a ping-ping-pong-pong is 380
microseconds, and assuming that the load generator takes 1 microsecond
(say) to send a request to the middle-tier server, I must achieve
close to saturation throughput when there are ~380 outstanding
requests? That doesn't seem to be true, though.

Therefore, I would like to look at the *number of queued tags*, when
there are 100K outstanding requests vs. 380 outstanding requests, to
see why such a large number of outstanding requests are necessary to
achieve a saturation throughput.

Regards,
Akshitha Sriraman
Ph.D. Candidate
Computer Science | University of Michigan, Ann Arbor

[201...@gmail.com]

I have same question as your.

在 2017年3月16日星期四 UTC+8下午10:01:40，aksh...@umich.edu写道：

[ncte...@google.com]

The number of queued tags is not available via any public api for the completion queue. I will add a github issue to add that to our internal tracing of completion queues, as I agree that it could be useful data.

[ncte...@google.com]

For now, try running your code under debug mode, with the pending_tags enabled:

export GRPC_VERBOSITY=DEBUG

export GRPC_TRACE=pending_tags