Some performance tests on gevent and libevent latencies

I set out to test the bare minimum reaction times for gevent and its underlying libevent library this morning. The exact versions used are gevent 0.13.1 and libevent 1.4.2 - not the most updated but fairly common.

The testing method I used was to run a TCP client and a server in the same process and let them ping-pong each other, and measure the rate of ping-pong requests. What this means is basically the absolute best reaction times for gevent and libevent in terms of TCP socket events. As a control experiment I also did a gevent queue ping-pong between two greenlets.

The source code of the two simple tests can be found below:

libevent test case:
http://tixxme.com/~martinkou-public/benchmark.c
gevent test case:
http://tixxme.com/~martinkou-public/benchmark.py

And here are the results -

Macbook Pro 2007 (2.2GHz Core 2 Duo/4GB RAM/OSX 10.6.6)

Martin-Kous-MacBook-Pro:testgswitch martinkou$ ./benchmark
25441.49 roundtrips per second
Martin-Kous-MacBook-Pro:testgswitch martinkou$ ./benchmark.py
test_tcp_socket: 8722.40 roundtrips per second
test_queue: 265788.63 roundtrips per second

Xeon Server (Xeon X3450/8GB RAM/Ubuntu Server 10.04)

martinkou@hydrogen:~/Development/levent-test$ ./benchmark
105852.88 roundtrips per second
martinkou@hydrogen:~/Development/levent-test$ ./benchmark.py
test_tcp_socket: 14124.71 roundtrips per second
test_queue: 430830.17 roundtrips per second

So, despite gevent's awesome performance among all Python concurrent I/O libraries - it still has plenty of space for improvement. This is actually a pretty good news for the developers of gevent and similar concurrent I/O libraries in Python. Because it means the more awesome things are still to come.