Basic performance comparison test for RPC framework

RPC framework: GRPC, Thrift, Wildfly, Dubbo

Original link: http://www.open-open.com/lib/view/open1426302068107.html

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 four open source projects for testing: GRPC, Thrift, Wildfly, Dubbo. To simplify, test examples are simply modified using the project's own demo or sample, which makes the cross-process network calls consistent.

GrpcHttps://github.com/grpc/grpc

2. 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.

4. Test example for routeguideclient

6. IDL is Route_guide.proto

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

   Testclientsync client = new Testclientsync ("localhost", 8980); try {  final long startTime = System.nanotime ();  for (int i = 0; i < 10000; i++)    client.getfeature (409146138, -746188906);  Final Long endTime = System.nanotime ();  Info ("Method 1:" + (Endtime-starttime));}

   
   

   public void getfeature (int lat, int. lon) {  try {point    request = Point.newbuilder (). Setlatitude (LAT). Setlongitude (Lon). Build ();    Feature Feature = blockingstub.getfeature (request);  } catch (RuntimeException e) {    logger.log (level.warning, "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.

Thrifthttp://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  (int i = 0; i < 10000; i++)     diff = Client.calculate (1, work);} catch (invalidoperation io) {  System.out.println ("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.0http://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 are here to test the remote EJB invocation capability in the Wildlfy, and the chosen Wildfly8.2 is the latest stable version currently released. 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.

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

2. 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 (int a, int b);}

   
   

   int sum=0;final Long startTime = System.nanotime (); for (int i = 0; i < 10000; i++) {         sum = Statelessremotecalculato R.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-snapshothttps://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 {    String hello = demoservice.sa Yhello ("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.

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 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.

From: http://www.useopen.net/blog/2015/rpc-performance.html

Basic performance comparison test for RPC framework