我們有一個(gè)相當(dāng)復(fù)雜的系統(tǒng)，它將不同的數(shù)據(jù)源拼接在一起，為用戶提供產(chǎn)品推薦。這些組件通常會(huì)調(diào)用我們正在運(yùn)行的一個(gè)或多個(gè) TensorFlow Serving 模型。即使在負(fù)載下，這也很好，直到最近我們的一些最終 REST API（使用 Sanic 框架）現(xiàn)在有時(shí)需要 10 秒以上才能返回。使用cProfile，看來問題是gRPC通道掛起。但它似乎與我們最終的網(wǎng)絡(luò)服務(wù)層中的某些東西隔離。當(dāng)我單獨(dú)為 TensorFlow Serving 組件運(yùn)行下面的代碼時(shí)，它可以輕松地完成一系列隨機(jī)輸入，沒有任何問題。這是我們正在運(yùn)行的代碼，刪除了一些特定細(xì)節(jié)：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這是由另一個(gè)函數(shù)調(diào)用的，該函數(shù)最終由如下所示的路由調(diào)用：@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我在這里缺少一些基本的東西嗎？當(dāng) TensorFlow Serving 服務(wù)沒有明顯的負(fù)載問題時(shí)，為什么這些請(qǐng)求會(huì)突然花費(fèi)這么長時(shí)間并掛起？為了仔細(xì)檢查，我們實(shí)際上很快在 FastAPI 中重新實(shí)現(xiàn)了其中一條路由，雖然它可能好一點(diǎn)，但超時(shí)仍然不斷發(fā)生。更新：作為另一項(xiàng)測(cè)試，我們使用 TensorFlow Serving REST HTTP API 重新實(shí)現(xiàn)了所有內(nèi)容。你瞧，問題完全消失了。不過我覺得 gRPC 應(yīng)該更好。仍然無法弄清楚為什么它被掛起。