Basic performance comparison test for RPC framework

GRPC is Google's latest open source software, based on the newest HTTP2.0 protocol and supports many common programming languages. We know that HTTP2.0 is a binary-based version of the HTTP protocol upgrade that is currently being supported by major browsers. We can imagine how "nice" it would be to be able to interact directly with the services of a variety of languages using the existing open source serialization library, such as PROTOBUF, to support HTTP2.0 in the future.

GPRC's Java implementation of the underlying network library is Netty, and is used for the latest NETTY5.0.0.ALPHA3 development, because the latest version has made a lot of improvements to HTTP/2. In order to cross-language, GPRC, like other schemes, uses an interface description language similar to the old IDL, using the PROTOC compiler in its own PROTOBUF project to generate the skeleton code. This is consistent with the thrift principle of the most popular Facebook open source, now the Apache top project.

I'm more curious about how the new framework is performing, and how it compares to the existing RPC open source scheme. It took some time to make a simple comparison. I have chosen the following five open source projects for testing: GRPC, Thrift, Wildfly, Dubbo, JBoss EAP. To simplify, test examples are simply modified using the project's own demo or sample, which makes the cross-process network calls consistent.

Grpc HTTPS://GITHUB.COM/GRPC/GRPC

1. Get the latest version from the GitHub master trunk and compile it according to the documentation. As mentioned above, the network framework is Netty5, based on the latest HTTP/2.

2. Test example for Routeguideclient

3. IDL is Route_guide.proto

4. Select the Getfeature method, remove the unused statements and screen output, make 10,000 synchronous calls.

 Testclientsync client = new  testclientsync ("localhost", 8980); try     Long  startTime = System.nanotime ();  for  (int  i = 0; i < 10000; i++< Span style= "color: #000000;"  >) client.getfeature ( 409146138, -746188906 final  long  endTime "= System.nanotime (); Info ( Method 1: "+ (endTime- StartTime);}  

 Public void getfeature (intint  lon) {  try  {    =  Point.newbuilder (). Setlatitude (LAT). Setlongitude (Lon). Build ();     = blockingstub.getfeature (request);   Catch (RuntimeException e) {    "RPC failed", e);     Throw e;  }}

Executes multiple times, recording the time required.

GRPC also has a non-blocking method of invocation, but because of the time constraints, in order to simplify the test, I only use the standard server boot, asyncstub in large concurrent access error, time is also longer, so this test does not have the results of this method of data.

Thrift http://thrift.apache.org

1. Get the latest 0.9.2 version from the Apache website, and natively compile the compiler and Java Runtime Environment for C.

2. Test example for Javaclient.java

3. IDL Tutorial.thrift

 int   diff;  final  long  startTime = System.nanotime ();  try   for  ( i = 0; I < 10000; I++) diff  = client.calculate (1 catch  " Invalid operation: "+ io.why);}  final  long  endTime = System.nanotime (); System.out.println ( Method 1: "+ (Endtime-starttime)); 

Thrift uses the classic network port-based RPC, which is the most efficient and can be seen in the final summary data.

Wildfly 8.2.0 http://www.wildfly.org

Wildfly is the JBoss application server renamed by Jbossas, which realizes the complete Java EE specification. We know that the remote RPC calls in Java EE are defined in the EJB specification. We're here to test the remote EJB invocation capability in the WILDLFY,

1. The selected Wildfly8.2 is the latest stable version of the current release. This version also supports Port multiplexing, that is, EJB remote calls are reused over HTTP ports, and the upgrade mechanism of HTTP is used for binary runtime negotiation upgrades. Although not pure HTTP/2, but also the operating mechanism is similar.

2. The test example selects the remote EJB invocation example in the Jboss-eap-quickstarts project Remoteejbclient.java

3. The benefit of pure Java RPC Scheme is no need to have IDL file definition and compile the process of generating code, as long as the interface can be negotiated

 Public Interface remotecalculator {    int Add (intint  b);}

int sum=0; Final long startTime = system.nanotime ();  for (int i = 0; i < 10000; i++) {         = Statelessremotecalculator.add (A, b);} Final long endTime = system.nanotime (); System.out.println ("Method 1:" + (Endtime-starttime));

Call the stateless Sessionbean method 10,000 times, and the corresponding remote EJB service is an EJB deployed in the Wildfly application server.

Dubbo 2.5.4-snapshot Https://github.com/alibaba/dubbo

Dubbo is an extremely member of the Ali group Open source RPC framework, widely used in many Internet companies and enterprise applications. Both the Protocol and the serialization framework can be pluggable and distinct features. The same remote interface is based on Java Interface and is easy to develop with the spring framework. It can be conveniently packaged into a single file, run independently, and be consistent with the current microservices concept.

1. Using the master backbone in GitHub, the current version is 2.5.4-snapshot

2. Test examples use the demo to modify Demoaction.java

 Public Interface Demoservice {    string SayHello (string name);}

Final long startTime = system.nanotime ();  for (int i = 0; i < 10000; i + +)    {try  {        = Demoservice.sayhello ("World" +  i);     Catch (Exception e) {        e.printstacktrace ();    }} Final long endTime = system.nanotime (); System.out.println ("Method 1:" + (Endtime-starttime));

Check the input log file for elapsed time after the call is complete.

Redhat JBoss EAP 6.3.2 Link

EAP is the commercial version of Jbossas and implements the complete Java EE specification.

1. EAP6 is built on a later version of AS7.2, and Red Hat offers business support.

2. AS7 after 7.2, the Community edition has not been released, the ability of enterprises can be compiled from the source code to use, EAP6.3 based on AS7.4 branch building, soon released EAP6.4 based on the AS7.5 branch build, no accident this will be the last EAP6 version.

3. AS7 has not yet been fully port-multiplexed like Wildfly, short-range EJB calls are done via a standalone port, based on JBossRemoting3 's network connection management capabilities.

4. Examples of remote EJB calls in Jboss-eap-quickstarts projects are still selected in the test example

 Public Interface remotecalculator {    int Add (intint  b);}

Records the length of time after 10,000 calls.

Data results

Finally, after 4 rounds of testing, the results of uninterrupted 10,000 remote RPC calls are as follows:

We can see that the thrift is the most efficient and probably one order of magnitude ahead. The performance data for the other three projects are in the same order of magnitude, from high to low to Jbosseap, Dubbo, Wildfly, and Grpc respectively.

The following points need to be explained:

1. In order to simplify the test, I did not choose the same call interface, but the use of the project comes with the convenience of modifying the sample program. The interfaces of GRPC and thrift have object passing, which is slightly more complicated.

2. Not a rigorous performance testing process, such as no preheating process, and the tests are running on my desktop machine, not completely restored to a "clean" state.

3. are simple server single process instances, standard demonstration examples, no special optimizations and setup of multiple thread pools. The client invocation is also the simplest blocking multiple-call stress test. It should be more objective to test with multiple machines, multiple threads, and asynchronous non-blocking calls in multiple environments, and have the opportunity to continue to improve.

4. You have not previously seen a performance comparison of RPC calls based on HTTP/2, which should theoretically be lower than the classic port-based RPC scenario. This test results can be a simple proof of this conjecture. Thrift's data is far ahead. Grpc is still in development, based on the Netty or Alpha version, and the non-blocking approach has no final data. I want to be patient, give grpc some time, it will make us amazing.

5. Wildfly good performance, to know that its server is a complete Java EE servers ah. But sometimes, I'll try. How efficient is the classic RMI connection, and it would be better to have an order of magnitude with thrift.

6. Dubbo performance is also excellent, and the protocol layer can be replaced, there should be a greater increase.

7. My tests were on an outdated notebook, constrained by conditions, with no advanced G-level network and multiple servers for standardized performance testing. If a friend who works in the Internet or business has the conditions and is willing to fully complete the test, please contact me and I will complete my test setup environment, share the code, and help complete it. I think the result will be more meaningful.

Fill in a note

1. The first four test times for 2015-03-11,03-21 joined the EAP6.3.2 test, which is good for jbossremoting-based EJB remote call testing. and thrift into an order of magnitude, the EJB function is very rich, with transaction, security and other advanced enterprise-level component features.

2. WILDFLY8 is configured to use remote invocation options similar to EAP, and the efficiency and EAP should be consistent.

Basic performance comparison test for RPC framework