Direct calls all milliseconds are close to 0, which means that the program processing almost no time spent, the record of all the time is spent on remote calls.

2. RMI calls

As envisioned, RMI is rightfully the fastest, with the fewest millihours in almost all cases. The disparity with other protocols is especially noticeable in the case of complex data structures and large amounts of data.

In order to give full play to the performance of RMI, another test class, do not use Spring, with the original form of RMI (inherited UnicastRemoteObject object) to provide services and remote invocation, and Spring on POJO wrapped into the RMI efficiency comparison. The results show that the two are basically the same , Spring provides a slightly faster service .

Preliminarily, this is because Spring's proxy and caching mechanism is more powerful, saving the time of object refetching.

3, Hessian call

caucho's resin server is claimed to be the fastest server, in the field of java has a certain degree of popularity. Hessian as a part of the resin, its design is also very streamlined and efficient, and the actual operation of the situation has proved this. On average, Hessian is about 20% slower than RMI, but this is only in the case of a particularly large amount of data, data structure is very complex to reflect the situation , medium or small amount of data, Hessian is not slower than RMI.

The benefit of Hessian is that it is streamlined and efficient, can be used across languages, and the protocol specification is open, we can develop an implementation of its protocol for any language. Currently there are implementations in java, c++, .net, python, ruby. There is no delphi implementation yet.

Additionally, Hessian combines very well with WEB servers, and with the mature functionality of WEB servers, it has a great advantage in dealing with a large number of users accessing concurrently, in terms of resource allocation, thread queuing, and exception handling can be guaranteed by mature WEB servers. RMI itself does not provide a multi-threaded server. Moreover, RMI needs to open firewall ports, Hessian does not.

4, Burlap call

Burlap and Hessian are caucho company's open-source products, but Hessian binary way, and Burlap using xml format.

Test results show that Burlap in the data structure is not complex, the data volume is medium, the efficiency is still acceptable, but if the data volume is large, the efficiency will drop sharply. On average, Burlap's invocation milliseconds are 3 times that of RMI.

In my opinion, there are two reasons for its low efficiency, one is that XML data describes too much content, the same data structure, its transmission is much larger; on the other hand, as we all know, the parsing of xml is more resource-consuming, especially for the case of large amounts of data is even more so.

5, HttpInvoker call

HttpInvoker SpringFramework is provided by the JAVA remote invocation method , using the java serialization mechanism to handle the transfer of objects. From the test results , its efficiency is still possible , and RMI is basically the same .

However, it can only be used for communication between JAVA languages, and, moreover, requires that the client and server are using the SPRING framework.

Additionally, HttpInvoker has not been tested in practice , we have not found the application of this protocol project .

6, web service call

The test selected apache's AXIS component as the implementation of WEB SERVICE, AXIS in the field of WEB SERVICE is relatively mature and old.

In order to test only the data transfer and encoding, decoding time, both the client and server side use the cache, the object only need to be instantiated once. However, the test results show that web service is still 10 times slower than other communication protocols.

When considering transfers with multiple references to the same object, web service lags even further behind. This is because protocols such as RMI, Hessian, and others can pass references, whereas web service has as many copies of the object entity as there are references.

Web service transmits too much redundant information is one of the reasons for its slow speed, monitoring found that the same access request, describing the same data, web service returns 6.5 times the amount of data than the hessian protocol. In addition, the processing of WEB SERVICE is also very time-consuming, the current xml parser is generally not efficient, processing xml <-> bean is very resource-consuming. From the test results, the off-site call is faster than the local call, but also from the side of its milliseconds are mainly used in encoding and decoding xml files. This is more serious than redundant information, redundant information occupies only network bandwidth, while the resource consumption of each call directly affects the load capacity of the server. (MS engineers have said that you can't load more than 100 concurrent users with WEB SERVICE.)