คุณไม่ได้กล่าวถึงการแก้ไขปัญหาที่คุณทำเพื่อให้ได้ข้อสรุปว่าเกิดจากการเรียก RPC มากเกินไป หรือรายละเอียดใดๆ เกี่ยวกับสถานะของการเชื่อมต่อเครือข่าย ณ จุดที่เกิดความล้มเหลว ฉันถือว่าข้อผิดพลาดนี้มาจากการที่พอร์ตหมดเนื่องจากขาดการรวมการเชื่อมต่อ
ในการตรวจสอบการหมดพอร์ตให้ใช้ netstat เพื่อรับสถานะของพอร์ตบนเซิร์ฟเวอร์ หากมีจำนวนพอร์ตมากเกินไป คุณอาจมีปัญหาพอร์ตหมด
gRPC รวบรวมการเชื่อมต่อโดยอัตโนมัติ อย่างไรก็ตาม โค้ดที่เขียนไม่ดีสามารถหยุดสิ่งนี้จากการทำงานได้อย่างถูกต้องโดยการสร้างช่อง gRPC ใหม่มากเกินไป แทนที่จะใช้ช่องที่มีอยู่เดิมซ้ำ ฉันได้อ้างอิงเอกสารของ Microsoft เนื่องจากมีคำอธิบายว่าการสร้างช่องใหม่ส่งผลให้เกิดการเชื่อมต่อ HTTP/2 ใหม่ได้อย่างไร
ในการแก้ไขปัญหานี้ คุณจะต้องประเมินรหัสของคุณและปรับเปลี่ยนเพื่อนำช่องสัญญาณกลับมาใช้ใหม่อย่างเหมาะสมยิ่งขึ้น
แนวทางปฏิบัติที่ดีที่สุดด้านประสิทธิภาพด้วย gRPC
ควรใช้ช่องสัญญาณ gRPC ซ้ำเมื่อทำการเรียก gRPC การใช้แชนเนลซ้ำทำให้สามารถเรียกมัลติเพล็กซ์ผ่านการเชื่อมต่อ HTTP/2 ที่มีอยู่ได้
หากมีการสร้างแชนเนลใหม่สำหรับการเรียก gRPC แต่ละครั้ง ระยะเวลาที่ใช้ในการทำให้เสร็จสมบูรณ์อาจเพิ่มขึ้นอย่างมาก การโทรแต่ละครั้งจะต้องมีเครือข่ายไป-กลับหลายครั้งระหว่างไคลเอนต์และเซิร์ฟเวอร์เพื่อสร้างการเชื่อมต่อ HTTP/2 ใหม่:
แนวทางปฏิบัติที่ดีที่สุดด้านประสิทธิภาพ
นำสตับและแชนเนลกลับมาใช้ใหม่เสมอเมื่อเป็นไปได้
ในขณะที่ทำเช่นนั้น คุณอาจพิจารณาใช้ซ็อกเก็ตโดเมน Unix มากกว่าซ็อกเก็ต TCP หากในที่สุดแอปพลิเคชันเหล่านี้จะทำงานกระจายไปยังหลายเครื่อง คุณควรยึดติดกับซ็อกเก็ต TCP หากจะทำงานบนเครื่องเดียวกันเสมอ คุณควรพิจารณาซ็อกเก็ตโดเมน Unix
วิธีสร้างบริการ GRPC ผ่านซ็อกเก็ตในเครื่องแทนที่จะเป็น inet ใน scala/java
เซิร์ฟเวอร์ gRPC ใน Python พร้อมซ็อกเก็ตโดเมน Unix