Zbr's days.

About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Thu, 30 Nov 2006

Hoax or not? New kevent benchmark.

I've completed a bunch of kevent updates including major kevent interface changes and will release new version soon. I've also created some locking changes, which I call speculative locking (i.e. some fields (ret_flags mostly) can be updated without locks, but it should not harm the system), which can be wrong, but results are impressive.

Hardware setup.
Client: Intel Core Duo 3.4 Ghz (run with 3.7 Ghz each core), 2 GB of RAM, sky2 driven gigabit NIC (Marvell 88E8053).
Server: AMD Athlon 64 3500+ 2.2 Ghz, 1 GB of RAM, r8169 gigabit NIC.

Software.
Both client and server systems have this network timewait socket setup:

# echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
# echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
# ulimit -n100000
it is the only changes from default startup.

Client runs Apache benchmark utility, which was started with following command line:
  ab -n80000 -c8000 http://192.168.0.48/
i.e. 80k requests total with 8k requests started concurrently.

Results.
kevent about 7200-7400 requests per second
epoll about 4300-5300 requests per second
With 10k concurrence performance drops to
kevent about 4000 requests per second
epoll about 3800 requests per second

it is possible that I made some errors in that benchmarks though, so I will not publish results to linux-kernel@ or make awailable from kevent homepage.

Update: even without speculative lock changes I got the same outperforming results. Kernel is compiled for SMP setup, all debugging is turned off (in my previous run on that platform I had some debugging options turned on, and performance was about the same and even worse for kevent), preemption model is 'Low-Latency Desktop'.

Update 2: forgot to say, that web server is lighttpd-1.4.13.

/devel/kevent :: Link / Comments ()