@grpc/grpc-js: Streaming throughput is about half of Java equivalent

[zeodtr]

Problem description

@grpc/grpc-js: Streaming throughput is about half of Java equivalent.

Reproduction steps

I've attached a ZIP file. Attachment: TestGrpc.zip The ZIP file includes the following programs.

• Node.js grpc server that has a server-streaming rpc function. The rpc function just sends a stream of a string.
• Node.js grpc client that uses the rpc function.
• Java grpc client that uses the rpc function. (A Java 1.8 spring boot application)

The steps are as follows:

1. Unzip attached TestGrpc.zip.
2. In NodeJS directory, run npm install.
3. run node TestGrpcServer.js on one command window.
4. Node.js client case:
   1. run node TestGrpcClient.js on the other command window and wait. In about 30 seconds, result will be shown.
5. Java client case: I will explain it with IntelliJ IDEA Community Edition.
   1. Run IntelliJ IDEA Community Edition.
   2. Using File -> New -> Project from Existing Sources..., open Java/TestGrpcClient/pom.xml.
   3. In the toolbar, click Add Configuration.... In Run/Debug Configurations, add an Application configuration, with Main class: setting to com.example.TestGrpcClient.TestGrpcClientApplication.
   4. Run the configuration by clicking 'play'-shaped button and wait. In about 20 seconds (excluding the build step), result will be shown.

On my windows 10 PC and a linux machine, Node.js grpc client took about 26 seconds to receive 10,000,000 strings. Java grpc client took about 16 seconds to receive 10,000,000 strings.

It was somewhat unexpected that the Node.js version is about twice as slow as the Java version regarding the streaming throughput. In my application, the throughput is very important, so this is a show-stopper for me. Can I improve this situation with some option tweaking?

Environment

• OS: Windows 10 x64, Linux CentOS 7.3
• Node version: 12.18.1 (On Windows 10 x64 machine, 12.18.3 and 14.8.0 showed the roughly same result.)
• Node installation method: nvm (Windows 10), download & tar xvfz (CentOS)
• If applicable, compiler version: For Java, Java 8 was used.
• Package name and version: @grpc/grpc-js 1.1.3 (On Windows 10 x64 machine, C-based grpc packages was even slower than @grpc/grpc-js)

Additional context

None.

[murgatroid99]

I'm sorry to tell you that this is not a surprising result. The @grpc/grpc-js library is a lot less mature than the Java gRPC library, so we have done a lot less work to optimize it. That is in addition to whatever inherent differences there may be between the runtimes.

[zeodtr]

@murgatroid99 FYI, I have another throughput-related benchmark results (though I cannot disclose the source code, since the server-part code is not actually a benchmark code, but just a part of our software). It's as follows: (as above, longer is worse)

• Java (grpc-netty-shaded 1.21.0, grpc-protobuf 1.21.0, grpc-stub 1.21.0): 90 sec
• Java (grpc-netty-shaded 1.31.0, grpc-protobuf 1.31.0, grpc-stub 1.31.0): 60 sec
• Java (grpc-okhttp 1.31.0, grpc-protobuf 1.31.0, grpc-stub 1.31.0): 4.5 sec (dramatic!)
• Node.js (@grpc/grpc-js): 13 sec (8.6 sec on a server machine)
• C++: 4.5 sec

The rpc function is a server-streaming function that sends a stream of string array (like a DBMS select result).

[charles-yubo]

Any news or updates on this one ?