foreword
The author made a simple comparison and analysis of the performance of dubbo and mac-rpc in terms of synchronous calls in the article "Dubbo vs mac-rpc Performance Evaluation: Synchronous Calls" . I didn't plan to evaluate the asynchronous call, because the difference between the two parties in the asynchronous method call is a bit large and not very symmetrical. However, many students discussed with me about the threading model of mac-rpc and the implementation of the underlying communication. I think it is better to write about it. You are welcome to continue discussing with me.
mac-rpc is my newly released work, for details, please visit: http://www.boarsoft.com
Implementation of Dubbo's asynchronous call
Regarding asynchronous calls, Dubbo's official documentation states that "NIO-based non-blocking implementation of parallel calls allows clients to call multiple remote services in parallel without starting multi-threading, with relatively low overhead compared to multi-threading." The fact is Is that so?
The author gives the following attributes of the dubbo:method tag of the method under test:
async="true" sent="false" return="true" timeout="6000"
In order to observe the resource consumption of both the service provider and the service consumer, we need to set the thread pool of dubbo to cached, and then use 300 threads to initiate calls in parallel, each thread performs 5000 asynchronous calls, and the service method simulation delay is 10ms , the result is as follows:
On the service consumer side :
On the service provider side :
Yes, that's right, in fact, the service consumer side starts an additional thread to initiate asynchronous processing. The final processing time will be slower than synchronous method calls, and CPU usage will increase significantly. The service provider side is not affected.
Since Dubbo does not support initiating multiple asynchronous calls at the same time within a thread, this means that the next asynchronous call is not allowed to be issued until the previous asynchronous call returns. Therefore, it is difficult to initiate a stress test through a loop like testing a synchronous method call.
Implementation of asynchronous call of mac-rpc
Similarly, in order to see the thread usage of mac-rpc during asynchronous calls, the author sets the size of the thread pool used by mac-rpc to 0~600, the queue to SynchronousQueue, and also uses 300 threads to initiate calls in parallel, each thread Execute 5000 asynchronous calls, the service method simulation delay is 10ms, and the results are as follows:
On the service consumer side :
On the service provider side :
Unlike dubbo, when mac-rpc is called asynchronously, the service consumer does not start additional threads to execute. So why the number of threads on the service consumer side is 400 instead of 300 and not 600? This is because mac-rpc starts an additional thread to process the return of the RPC call. This design makes mac-rpc slower when executing massively parallel low-latency, low-data-volume synchronous calls, but faster when processing high-latency, large-data-volume scenarios. The next version of mac-rpc will consider optimizing here.
Performance comparison test
testing method
In order to conduct a comparative test and eliminate unnecessary factors, we let both service parties use a fixed thread pool of size 600, cooperate with a LinkedBlockingQueue queue of size 600, and let the service method simulate a delay of 100ms, and only return 10 characters, and then use 300 threads initiate calls in parallel, each thread calls 2000 times, and retains the obtained Future object, gets it at the end of the program, and then observes the total time and resource consumption.
Test Results
When using a thread pool with a fixed size of 600, the service provider side of Dubbo displays the warning Thread pool is EXHAUSTED, and the service consumer side displays the warning Client session timed out, have not heard from server in 37125ms. It means that how the service consumer side fails to get the result, which will cause the thread of the service provider side to be occupied until it times out. This should be considered a serious design flaw of dubbo.
When using the cached thread pool, Dubbo cannot work at all, and the service provider status is as follows:
The service consumer status is as follows:
When the timeout time is 6 seconds, no matter what kind of thread pool is used, mac-rpc can be successfully completed. When the thread pool with a fixed size of 600 is used, the result is the best, and the average time is 104206ms, which is faster than the synchronous execution. doubled.
The service provider status is as follows:
Note: It can be seen that when the RPC request sent by the service consumer is completed, the service provider completes all requests after a period of time, the CPU drops to 0%, and the service consumer is still obtaining and processing the response returned by the server.
The service consumer status is as follows:
Test conclusion
mac-rpc wins on asynchronous method calls. It is superior in terms of performance, pressure resistance and stability. In addition, in addition to basic asynchronous method calls, mac-rpc also supports asynchronous notifications, asynchronous callbacks and other asynchronous forms, which are worth a try.