为什么这个 TensorFlow Serving gRPC 调用会挂起？

Question

我们有一个相当复杂的系统，它将不同的数据源拼接在一起，为用户提供产品推荐。这些组件通常会调用我们正在运行的一个或多个 TensorFlow Serving 模型。即使在负载下，这也很好，直到最近我们的一些最终 REST API（使用 Sanic 框架）现在有时需要 10 秒以上才能返回。使用cProfile，看来问题是gRPC通道挂起。但它似乎与我们最终的网络服务层中的某些东西隔离。当我单独为 TensorFlow Serving 组件运行下面的代码时，它可以轻松地完成一系列随机输入，没有任何问题。这是我们正在运行的代码，删除了一些特定细节：def get_tf_serving(model_uri, model_name, input_name, output_name, X):    channel = grpc.insecure_channel(model_uri, options=MESSAGE_OPTIONS)    stub = prediction_service_pb2_grpc.PredictionServiceStub(channel)    request = predict_pb2.PredictRequest()    request.model_spec.name = model_name    request.model_spec.signature_name = 'serving_default'    request.inputs[input_name].CopyFrom(util.make_tensor_proto(X.astype(np.float32), shape=X.shape))    result = stub.Predict(request, 4.0)    channel.close()    # imagine more stuff here doing something with the returned data    data = result.outputs[output_name].float_val        return data这是由另一个函数调用的，该函数最终由如下所示的路由调用：@doc.include(True)async def get_suggestions(request):    user_id = request.args.get('user_id', 'null')    count = int(request.args.get('count', 10))    data = # something that itself calls `get_tf_serving`    return data我在这里缺少一些基本的东西吗？当 TensorFlow Serving 服务没有明显的负载问题时，为什么这些请求会突然花费这么长时间并挂起？为了仔细检查，我们实际上很快在 FastAPI 中重新实现了其中一条路由，虽然它可能好一点，但超时仍然不断发生。更新：作为另一项测试，我们使用 TensorFlow Serving REST HTTP API 重新实现了所有内容。你瞧，问题完全消失了。不过我觉得 gRPC 应该更好。仍然无法弄清楚为什么它被挂起。

Answer 1

这里的问题不是 TensorFlow Serving 设置或 Python 代码，而是两个部分之间的网络配置方式。TensorFlow Serving 实例由 Kubernetes 编排，然后使用 Kubernetes 服务拼接在一起。正是 Python 代码调用的服务以及错误的配置导致了超时。

简而言之，由于 gRPC 依赖于 HTTP/2，因此由于多路复用而导致标准 Kubernetes 服务遇到一些问题，而多路复用本来是 gRPC 的优势功能之一。