What is the best practice of using python grpc as a server to serving data transfer service

Viewed 479

In python gRPC, I tried grpc aio streaming. If there is just one client, the speed is acceptable. But when the number of clients increases, data transfer speed is slower and slower. I tried multi processing with sync gRPC, but sometimes it still route the request to a busy one, then the result is slow than expected. I tried multiprocessing with aio gRPC as well, by each process serves an aio gRPC server. It seems no big difference with multiprocessing with sync gRPC.

In addition, during the testing, it seems that the server is waiting till the client gets the message, then the server send the next one. The server may be affected by some very slow client.

Overall, my question is: If python is the only option, what is the best practice of creating a Data transfer service using python gRPC?

1 Answers

gRPC is based on HTTP2 protocol, and giving gRPC the advantage of multiplexing over one connection. It's possible that the bandwidth between client and server is consumed by one client and one server setup. As for multiprocessing, the SO_REUSEPORT is not a perfectly balanced load balancing for HTTP. You might need to configure your own routing mechanism(proxy/gateway).

it seems that the server is waiting till the client gets the message

Emm... technically, the server implementation hands over the message buffer to transport, then yield to event loop. If there are multiple ongoing RPCs, the server will start processing other coroutines. See code: https://github.com/grpc/grpc/blob/3ffa94f5e7334b7fdee6b173c25d71d42b512ac7/src/python/grpcio/grpc/_cython/_cygrpc/aio/server.pyx.pxi#L142

If python is the only option, what is the best practice of creating a Data transfer service using python gRPC?

This question is a bit generic. If the throughput is the highest priority for the service, I would suggest to tune up the size of messages to MB-level. If there is no other compute-heavy workload, I would suggest to keep only one server process.

Related