Bạn không đề cập đến việc khắc phục sự cố mà bạn đã thực hiện để đi đến kết luận rằng điều này là do có quá nhiều cuộc gọi RPC hoặc bất kỳ chi tiết nào về trạng thái của các kết nối mạng tại thời điểm xảy ra lỗi. Tôi cho rằng lỗi này xảy ra do hết cổng do thiếu kết nối tổng hợp.
Để kiểm tra sự cạn kiệt của cổng, hãy sử dụng netstat để biết trạng thái của các cổng trên máy chủ. Nếu có quá nhiều cổng được liệt kê, bạn có thể gặp sự cố hết cổng.
gRPC gộp các kết nối tự động, tuy nhiên, mã được viết kém có thể ngăn điều này hoạt động bình thường bằng cách tạo quá nhiều kênh gRPC mới thay vì sử dụng lại các kênh hiện có. Tôi đã tham khảo tài liệu của Microsoft vì tài liệu này có mô tả về cách tạo kênh mới dẫn đến việc tạo kết nối HTTP/2 mới.
Để sửa lỗi này, bạn sẽ cần đánh giá mã của mình và sửa đổi mã để sử dụng lại các kênh một cách thích hợp hơn.
Các phương pháp hay nhất về hiệu suất với gRPC
Kênh gRPC nên được sử dụng lại khi thực hiện cuộc gọi gRPC. Việc sử dụng lại một kênh cho phép các cuộc gọi được ghép kênh thông qua kết nối HTTP/2 hiện có.
Nếu một kênh mới được tạo cho mỗi lệnh gọi gRPC thì lượng thời gian cần thiết để hoàn thành có thể tăng lên đáng kể. Mỗi cuộc gọi sẽ yêu cầu nhiều chuyến khứ hồi mạng giữa máy khách và máy chủ để tạo kết nối HTTP/2 mới:
Thực tiễn tốt nhất về hiệu suất
Luôn sử dụng lại sơ khai và kênh khi có thể.
Trong khi làm như vậy, bạn có thể xem xét ổ cắm miền Unix thay vì ổ cắm TCP. Nếu các ứng dụng này cuối cùng sẽ hoạt động được phân phối trên nhiều máy, bạn nên sử dụng ổ cắm TCP. Nếu chúng luôn chạy trên cùng một máy, bạn nên xem xét các ổ cắm tên miền Unix.
Cách tạo dịch vụ GRPC qua ổ cắm cục bộ thay vì inet trong scala/java
máy chủ gRPC bằng Python với ổ cắm tên miền Unix
