grpc-java bi-di stream performance - PullRequest
Новая
       13

grpc-java bi-di stream performance

0 голосов
/ 21 сентября 2018

Я просто использую пример routeguide в пакете grpc-java и пытался отправить 1 000 000 сообщений на сервер. 

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

Я обнаружил, что производительность хуже и много времени уходит на сборку мусора.

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

Есть ли способ улучшить базу производительности на примере маршрута?

1 Ответ

0 голосов
/ 03 октября 2018

Проблема с кодом в том, что он не соблюдает управление потоком данных на сервере.Вам необходимо привести наблюдателя к CallStreamObserver.Затем вы можете позвонить isReady(), чтобы проверить, может ли сервер принимать больше сообщений перед отправкой другого.Если сервер не готов, isReady() вернет false, и вам нужно будет подождать, пока он не будет.Вы можете сделать это, вызвав setOnReadyHandler() в наблюдателе потока вызовов, который уведомит вас, когда вы сможете отправить снова.

Причина в том, что gRPC буферизует ваши сообщения в памяти, если сервер не сможет принять больше.Обычно это не проблема, потому что большинство пользователей просто отправляют одно сообщение.Однако при отправке большого количества сообщений они будут заполнять память на стороне клиента и вызывать OOM, который вы видите.API gRPC спроектирован как неблокируемый, поэтому вызов onNext() не будет ждать готовности сервера.Если это произойдет, существует риск тупика.

...