Turn from:
http://blog.csdn.net/mindfloating/article/details/8622930
performance evaluation and analysis of Netty and Mina in the popular NIO FrameworkTest method Using Mina and Netty to implement a echoserver based on NIO to test the performance of network packets of different sizes Test environment Client-server: model Name:intel (R) Core (TM) i5-2320 CPU @ 3.00ghz cache size:6144 kb cpu cores: 4 jdk: 1.6.0_30-b12 network: 1000mb memory: -xms256m-xmx256m Linux: centos 5.7, Kernel 2.6.18-274.el5 test tool: jmeter v2.4 version: mina 2.0.7 netty 3.6.2.final configuration: mina Io-processor CpuNumber of cores executor CPU cores buffer Initial buffer size, set to 2048 (2k) netty boss &NBS P Netty default configuration 1 worker CPU cores Execut or   CPU In theory, echo-based applications do not configure the executor business execution thread pool for better performance and lower consumption, but consider in real business applications Real business scenario processing usually involves a variety of complex logical computations, caching, database, external interface access, in order to avoid the business execution delay blocking IO thread execution resulting in throughput degradation, usually separates the IO processing thread and the business processing thread, So our test cases also configured the business execution thread pool to examine the scheduling performance of their thread pools. mina thread pool settings IO processor:   ; ioacceptor acceptor = new niosocketacceptor (Integer.parseint (Iopool)); Executor:  ACCE Ptor.getfilterchain (). AddLast ("ThreadPool ", new executorfilter (Integer.parseint (Executorpool))); netty thread pool settings IO worker: new Nioworkerpool (Executors.newcachedthreadpool (), Integer.parseint (Iopool)) Executor: new Orderedmemoryawarethreadpoolexecutor (Integer.parseint (Executorpool), 0, 0) test results
| Mina |
Tps |
Cpu |
Network IO |
Art (average response time) |
90%RT (90% response time) |
| 1k |
45024/sec |
150% |
50mb/sec |
< 1ms |
1ms |
| 2k |
35548/sec |
170% |
81mb/sec |
< 1ms |
1ms |
| 5k |
10155/sec |
80D |
55mb/sec |
3 ms |
1ms |
| 10k |
8740/sec |
137% |
98mb/sec |
3ms |
4ms |
| 50k |
1873/sec |
128% |
100mb/sec |
16ms |
19ms |
| 100k |
949/sec |
128% |
100mb/sec |
33ms |
43ms |
| Netty |
Tps |
Cpu |
Network IO |
Art (average response time) |
90%RT (90% response time) |
| 1k |
44653/sec |
155% |
50mb/sec |
< 1ms |
1ms |
| 2k |
35580/sec |
175% |
81mb/sec |
< 1ms |
1ms |
| 5k |
17971/sec |
195% |
98mb/sec |
3 ms |
1ms |
| 10k |
8806/sec |
195% |
98mb/sec |
3ms |
4ms |
| 50k |
1909/sec |
197% |
100mb/sec |
16ms |
18ms |
| 100k |
964/sec |
197% |
100mb/sec |
32ms |
45ms |
Test reviews Mina and Netty in 1k, 2k, 10k, 50k, 100k message Large hour TPS close to Mina in 5k message there is an obvious anomaly (red callout), TPS Low, network IO throughput is low, compare Netty in 5k packet network IO throughput 98mb/ SEC (Basic proximity to the Threshold network card limit) 5k messages above the basic can be full of network IO, bottleneck in Io, so TPS and response time basically differ little. Question, why does the Mina have a noticeable decrease in IO throughput when the 5k message is present? Test analysis By analyzing the source code of Mina and Netty, it is found that there are some differences between the two frames on the buffer allocation strategy when processing IO read events. On the network IO processing, every time the program calls the socket API reads from TCP buffer the number of bytes is changed at any time, it will be affected by the packet size, operating system TCP buffer size, TCP protocol algorithm implementation, network link bandwidth of various factors. Therefore, the NIO framework, when dealing with each read event, also needs to allocate a buffer each time to temporarily store the read bytes, and the performance of the buffer allocation is a key factor that affects the network IO Framework program performances. below analyzes the dynamic assignment implementation of Mina and Netty buffer respectively mina buffer allocation method: The default implementation uses Heapbytebuffer, each Times are directly called bytebuffer.allocate (capacity) Direct assignment buffer allocation size forecast: Calculates the size of the allocated buffer based on the number of bytes actually read per read event, and if the actual read to byte fills the Bytebuffer, indicating that the amount of data from the network may be large and the allocated buffer capacity is insufficient, then enlarge the buffer one time. If the actual number of bytes read 2 times is less than half of the buffer capacity, then the buffer is reduced to half the original netty buffer allocation method &NBSP ; The default implementation uses Directbytebuffer, and the buffer cache is implemented, so long as the buffer size does not change, the allocated buffer & Nbsp;buffer Allocation size Prediction: Initializes a buffer size static allocation table as follows (intercept section), assuming that the current default buffer is 2048 [1024, 115 2, 1280, 1408, 1536, 1664, 1792, 1920, 2048, 2304, 2560, 2816, 3072, 3328, 3584, 3840, 4096] &N Bsp | | | | &N Bsp a &N Bsp;d b c &N bsp; Predict the buffer size that should be allocated the next time, based on the number of bytes actually read per read event. If the number of bytes actually read is greater than or equal to the current buffer (B position), the current buffer is increased to the C position, and each increment is 4 If the number of bytes actually read for 2 consecutive times is less than or equal to a The buffer size indicated by the position, then reduce the buffer to D position from the above comparative analysis, Mina uses a relatively simple buffer allocation and prediction method, buffer growth and reduction of the same ratio. The Netty uses a buffer allocation method with a relatively complex point, buffer increment faster decrement slower. It turns out that nettThe allocation of Y is more effective in avoiding the jitter problem in buffer allocation (suddenly large and small), and buffer allocation jitter is the culprit that affects IO throughput. Mina Test in the 5k message just produced buffer allocation jitter caused by IO throughput greatly affected, by modifying the Mina source code with a fixed buffer size to test effectively avoid buffer jitter, IO throughput also return to normal. However, in reality, fixed buffer is not an effective way to adapt to the complexity of various network environments, but the use of dynamic buffer allocation when the algorithm should be the primary consideration to avoid jitter. also can see Netty CPU consumption is significantly higher than Mina many, suspect Netty adoption of executor implementation (Orderedmemoryawarethreadpoolexecutor) There are more lock competition and thread context switching. The following is a set of test data that is netyy when not using executor, while other indicators are similar, but the CPU is significantly reduced.
| Netty |
Cpu |
| 1k |
75% |
| 2k |
125% |
| 5k |
126% |
| 20H |
126% |
| 50k |
118% |
| 100k |
116% |
Test Summary Mina: Need to further optimize its buffer allocation, to avoid the allocation jitter caused by the IO throughput fluctuations Netty: need to further optimize the default executor implementation, reduce CPU consumption actually netty2 and Mina all came from the same person Trustin Lee, and later he turned The Apache project team gave Netty to the community for continued maintenance and then redesigned the Mina framework. Mina API interface design is significantly more elegant than Netty from the user experience.
Comparison and analysis of the performance of Netty and Mina (RPM)
