Python grpc.aio.UnaryUnaryCall and blocking asyncio?

[Charles Chan]

Hello,

We are using Python 3 to implement a HTTP server using asyncio, the HTTP server initiates a grpc.aio.UnaryUnaryCall to the backend to retrieve a (large) file. We notice these requests seems to be block other requests on the asyncio server.

How does grpc.aio.UnaryUnaryCall work underneath the covers? Does it yield to the event loop while reading data, in between every chunk of data? Do we have to use grpc.aio.UnaryStreamCall to read() and yield periodically?

Thanks

Note: I found another thread (https://groups.google.com/g/grpc-io/c/r7thQeaAYYI/m/2s8qad9ZBAAJ) but it doesn't fully answer my question.

[Richard Belleville]

> Does it yield to the event loop while reading data

It absolutely should be and if it's not, then we would consider it a bug. I will note that deserializing the protobuf is a blocking operation, so a very complex proto (or simply a very big one, where a copy takes a long time) could explain the issue you're seeing.

> Do we have to use grpc.aio.UnaryStreamCall to read() and yield periodically?

If the issue is the deserialization time, then I would expect this to help.

Any chance you can do a little ad-hoc measurement to determine what the source of the blocking is? If this is a common problem, I suppose we could do a native thread offload for protobuf serialization where we release the GIL, do the deserialization in native code, and provide an async def deserialization method.

[Paul Milesi]

Thank you Richard for your answer.

Our max payload size going through grpc.aio.UnaryUnaryCall is ~20MB . It does not seem crazy big for serializing or deserializing steps, but with many simultaneous requests, could that add up ?

We'll look at doing some more ad-hoc measurements to determine the source of the blocking.

Thanks