使用gevent和grpc扩展问题 [英] Scaling issues using gevent and grpc

问题描述

由于已解决gevent/grpc兼容性问题，因此我尝试使用它.

Since the gevent/grpc compatibility issue has been fixed, I was trying to use it.

我用示例脚本对其进行了测试

I tested it out with a sample script

from gevent import monkey
monkey.patch_all()

import grpc._cython.cygrpc
grpc._cython.cygrpc.init_grpc_gevent()

import grpc
import time
import sys

channel = grpc.insecure_channel('localhost:5000')
stub =hello_word_pb2_grpc.HelloWordStub(channel)

data = hellow_word_pb2.HelloWorld()

num_requests=3000
start=time.time()
futures = []

# Make async requests
for i in range (num_requests):
  futures.append(stub.HelloWorld.future(req))

# Wait for the requests to complete
for i in range (num_requests):
  try:
    result = futures[i].result()
    # Do something with the result
  except Exception as e:
    print(e)
end = time.time()
print(end - start)

现在没有此补丁

import grpc._cython.cygrpc
grpc._cython.cygrpc.init_grpc_gevent()

完成3000次请求需要0.456701040268秒

it takes 0.456701040268 seconds to finish 3000 reqs

现在有补丁

import grpc._cython.cygrpc
grpc._cython.cygrpc.init_grpc_gevent()

需要1.06秒.

任何建议都可能导致兼容性补丁出问题.

Any suggestions what could go wrong with the compatibility patch.

很明显，如果我将请求数减少到1000，并在每个调用中进行3个具有1000个异步请求的呼叫，则总共3000个请求所花费的时间少于1.06.但是我想知道是什么原因导致修补程序变得如此缓慢?

Obviously if I decrease the number of reqs to 1000 and make 3 calls with 1000 async reqs in each call, the time it takes for the total 3000 reqs is lesser than 1.06. But I wanted to know what is causing the patching to make it so slow?

我发现这里提到了类似的内容-https://github.com/grpc/grpc/blob/master/src/python/grpcio_tests/commands.py#L115

I found something similar mentioned here - https://github.com/grpc/grpc/blob/master/src/python/grpcio_tests/commands.py#L115

有关系吗?

推荐答案

在标准gRPC Python实现中，异步请求在后台线程上执行.由于GIL，纯Python程序无法获得与CPU绑定的任务的并发性，但是由于gRPC是基于c的库，因此许多gRPC工作可以同时完成.

In the standard gRPC Python implementation, asynchronous requests are performed on background threads. Pure Python programs can't get concurrency for CPU bound tasks because of the GIL, but because gRPC is a c-based library, a lot of the gRPC work is able to be done concurrently.

启用gEvent会强制整个程序在单个线程上运行.您失去了上述并发性.此外，与c相对，在Python中处理IO会产生一些开销.

Enabling gEvent forces the entire program to run on a single thread. You loose the concurrency mentioned above. Additionally, there is some overhead in handling the IO in Python as opposed to c.

如果您的目标是最大程度地提高性能，则建议您使用默认的gRPC实现.gRPC gEvent主要用于兼容性.

If your objective is to maximize performance, I'd recommend using the default gRPC implementation. gRPC gEvent is primarily intended for compatibility.

这篇关于使用gevent和grpc扩展问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！