grpc-java bi-di流性能

Question

我简单地使用了grpc-java包中的routeguide示例，并尝试向服务器发送1,000,000条消息。

for (int i=1; i<=1000000; i++){
    requestObserver.onNext(request);
}

我发现性能更差，并且在GC上花费了大量时间

0.286: [GC (Allocation Failure) [PSYoungGen: 64512K->10237K(74752K)] 64512K->30691K(245760K), 0.0209037 secs] [Times: user=0.10 sys=0.01, real=0.02 secs] 
0.335: [GC (Allocation Failure) [PSYoungGen: 65117K->10226K(139264K)] 85570K->80123K(310272K), 0.0369838 secs] [Times: user=0.28 sys=0.01, real=0.04 secs] 
0.956: [GC (Allocation Failure) [PSYoungGen: 139250K->10224K(139264K)] 209147K->121117K(310272K), 0.0665830 secs] [Times: user=0.28 sys=0.02, real=0.07 secs] 
1.342: [GC (Allocation Failure) [PSYoungGen: 139248K->10208K(268288K)] 250141K->163711K(439296K), 0.0384561 secs] [Times: user=0.24 sys=0.00, real=0.04 secs] 
1.380: [Full GC (Ergonomics) [PSYoungGen: 10208K->0K(268288K)] [ParOldGen: 153502K->146307K(303104K)] 163711K->146307K(571392K), [Metaspace: 15761K->15761K(1062912K)], 0.5195652 secs] [Times: user=2.81 sys=0.01, real=0.52 secs] 
2.411: [GC (Allocation Failure) [PSYoungGen: 258048K->10208K(268288K)] 404355K->232472K(571392K), 0.0425126 secs] [Times: user=0.26 sys=0.02, real=0.04 secs] 
2.978: [GC (Allocation Failure) [PSYoungGen: 268256K->88032K(429056K)] 490520K->315472K(732160K), 0.0456898 secs] [Times: user=0.26 sys=0.05, real=0.04 secs] 
3.024: [Full GC (Ergonomics) [PSYoungGen: 88032K->0K(429056K)] [ParOldGen: 227440K->288136K(538624K)] 315472K->288136K(967680K), [Metaspace: 15765K->15765K(1062912K)], 0.4887699 secs] [Times: user=3.11 sys=0.02, real=0.49 secs] 
Sep 21, 2018 1:40:16 PM routeguide.RouteGuideClient info
INFO: Finished RouteChat
Heap
 PSYoungGen      total 429056K, used 331100K [0x000000076cf80000, 0x000000078ee80000, 0x00000007c0000000)
  eden space 340992K, 97% used [0x000000076cf80000,0x00000007812d7330,0x0000000781c80000)
  from space 88064K, 0% used [0x0000000788200000,0x0000000788200000,0x000000078d800000)
  to   space 103936K, 0% used [0x0000000781c80000,0x0000000781c80000,0x0000000788200000)
 ParOldGen       total 538624K, used 288136K [0x00000006c6e00000, 0x00000006e7c00000, 0x000000076cf80000)
  object space 538624K, 53% used [0x00000006c6e00000,0x00000006d87620b0,0x00000006e7c00000)
 Metaspace       used 15976K, capacity 16234K, committed 16384K, reserved 1062912K
  class space    used 1902K, capacity 1989K, committed 2048K, reserved 1048576K

基于routeguide示例，有什么方法可以提高性能吗？

Answer 1

代码的问题是它没有遵守服务器的流量控制。您需要将观察者转换为CallStreamObserver。然后，您可以调用isReady()检查服务器是否可以接受更多消息，然后再发送另一条消息。如果服务器还没有准备好，isReady()将返回false，您需要等待它准备就绪。您可以通过调用调用流观察器上的setOnReadyHandler()来完成此操作，该观察器将在您可以再次发送时通知您。

原因是，如果服务器无法接受更多消息，gRPC将在内存中缓冲您的消息。通常这不是问题，因为大多数用户只发送一条消息。但是，当发送大量消息时，它们会填满客户端的内存，并导致您看到的OOM。gRPC应用编程接口被设计为非阻塞的，因此onNext()调用不会等待服务器准备就绪。如果是这样的话，就有陷入僵局的风险。