Compare the event-handling effect of Muduo and libevent2 through the drum-spreading program

Before we compare the throughput of Muduo and Libevent2, we get the conclusion that Muduo is 18% faster than Libevent2. Some people will say that Libevent2 is not designed for the high throughput of the application scenario, such a more unfair, not win. For the sake of fairness, this time we use Libevent2 's own performance test program (drumming) to compare the Muduo and Libevent2 IO event processing efficiency in high concurrency situations.

Test object

Libevent 2.0.6-RC, source code package http://monkey.org/~provos/libevent-2.0.6-rc.tar.gz

Muduo 0.1.2-alpha, source http://muduo.googlecode.com/files/muduo-0.1.2-alpha.tar.gz SHA1 Checksum: 9e7da4b46ad87602dd206eaedf54e67c17dfe4e1. Must be compiled to release version.

Test environment

The software and hardware environment for testing is the same as "Muduo vs boost ASIO throughput" and "Muduo vs. Libevent2 throughput," and I ran tests on my laptop, and the results were attached.

Test content

The test scenario is: There are 1000 people in a circle, play the game of playing drums, the first 1th in the hands of a flower, he put the flowers to the right hand, the person who continue to put flowers to the right-hand side, when the flowers changed hands 100 times after the game stopped, record from the beginning to the end of time.

expressed by the program is, there are 1000 network connections (socketpairs or pipes) in which data is passed in sequence, one begins with 1 bytes in the 1th connection, and then reads the 1 bytes from the other end of the connection, writes the 2nd connection, and reads out to continue writing to the 3rd Connection until the program stops and records the time it takes to write 100 times.

The above is only one active connection scene, we actually tested 100 or 1000 active connections (that is, 100 flowers or 1000 flowers, evenly dispersed in the hands of the crowd), and the total number of connections (that is, the number of concurrent) from 100 to 100,000 (100,000). Note that each connection is a two file descriptor, and in order to run the test, you need to increase the number of files that each process can open, such as set to 256000.

Libevent2 's test code is located in Test/bench.c, I fixed a small bug in the 2.0.6-RC version, the revised code see http://github.com/chenshuo/recipes/blob/master/ Pingpong/libevent/bench.c

Muduo's test code is located in examples/pingpong/bench.cc, see http://gist.github.com/564985#file_pingpong_bench.cc

Test results and discussion

The first round, with 100 active connections and 1000 active connections, no timeout, read and write 100 times, test the total time of the game (including initialization) and event processing time (not including registration event watcher) with the number of connections (concurrency) changes. Specific explanation see Libev Performance Test document Http://libev.schmorp.de/bench.html, the difference is that we do not compare the performance of the timer event, only compare IO event performance. For each concurrent number, the program cycle 25 times, planing to the first warm-up data, after 24 times averaged. The test script is in http://github.com/chenshuo/recipes/blob/master/pingpong/libevent/run_bench.sh. This script was written by Marc Lehmann, author of Libev, and I used it slightly to test Muduo and Libevent2.

First round results, please look at the red and green lines first. The Red line is Libevent2 time, and the green wire is the muduo time. The smaller the number, the better. Note that the horizontal axis of the graph is logarithmic, with each order of magnitude 1, 2, 3, 4, 5, 6, 7.5, 10.