使用 python grpc 作为服务器来提供数据传输服务的最佳实践是什么
在 python gRPC 中，我尝试了 grpc aio 流。如果只有一个客户端，速度是可以接受的。但当客户端数量增加时，数据传输速度越来越慢。我尝试使用同步 gRPC 进行多处理，但有时它仍然将请求路由到繁忙的请求，然后结果比预期慢。我也尝试使用 aio gRPC 进行多处理，每个进程都服务于一个 aio gRPC 服务器。看起来与同步 gRPC 的多处理没有太大区别。
另外，在测试过程中，服务器似乎一直在等待客户端收到消息，然后服务器发送下一条消息。服务器可能会受到某些速度非常慢的客户端的影响。
总的来说，我的问题是：如果 python 是唯一的选择，那么使用 python gRPC 创建数据传输服务的最佳实践是什么？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
gRPC 基于 HTTP2 协议，赋予 gRPC 在一个连接上进行多路复用的优势。客户端和服务器之间的带宽可能被一台客户端和一台服务器设置消耗。至于多处理，SO_REUSEPORT 并不是一个完美的 HTTP 负载平衡。您可能需要配置自己的路由机制（代理/网关）。
Emm...从技术上讲，服务器实现将消息缓冲区移交给传输，然后屈服于事件循环。如果有多个正在进行的 RPC，服务器将开始处理其他协程。请参阅代码： https://github.com/grpc/grpc/blob/3ffa94f5e7334b7fdee6b173c25d71d42b512ac7/src/python/grpcio/grpc/_cython/_cygrpc/aio/server.pyx.pxi#L142
这个问题有点笼统。如果吞吐量是服务的最高优先级，我建议将消息大小调整到 MB 级别。如果没有其他计算量大的工作负载，我建议只保留一个服务器进程。
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).
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
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.