It seems that client request will share the same netty channel but streamId is different. so the request will queue in the omega side, sending the request to alpha one by one, this is channel multiplexing which http2 stream protocol provided. we can increase omega and alpha machine count to process large volume requests in theory. Or we can leverage original netty instead of grpc(http2) to increase throughput of single omega.
> On 15 Oct 2018, at 11:03 AM, fu chengeng <[email protected]> wrote: > > > The way grpc callbacks (StreamObserver) are thread-unsafe, the callbacks for > the same service can only be one after the other, which can become a > performance bottleneck > > https://grpc.io/grpc-java/javadoc/io/grpc/stub/StreamObserver.html > StreamObserver (grpc-all 1.15.1 > API)<https://grpc.io/grpc-java/javadoc/io/grpc/stub/StreamObserver.html> > Receives a value from the stream. Can be called many times but is never > called after onError(Throwable) or onCompleted() are called.. Unary calls > must invoke onNext at most once. Clients may invoke onNext at most once for > server streaming calls, but may receive many onNext callbacks. > grpc.io > > >
