[kqueue]

I believe you are testing the requests / sec and not replies / sec. While requests / sec matters a bit, you'll most probably be bottle-necking in your context switches. What matters is replies / sec. This is a more accurate measurement of your server performance and not OS bottlenecks. I'd use httperf for this matter.

[willvarfar]

I am confused. What context switches?

[kqueue]

Measuring requests per second is close to measuring the number of accept system calls you can do. Since it's a system call you have a context switch.

[jerf]

I would love to see "someone" do that benchmark; using epoll, accept as many sockets as possible, for the sake of argument let's stuff one byte down them, and then properly shut them down.

I'm curious how close to the limit of the underlying poll technology we're getting, because it seems like everyone is converging in roughly the same area, in an order-of-magnitude sense.

I also find myself wondering about the implications of these artificial benchmarks and the stuff Zed discussed here: http://sheddingbikes.com/posts/1280829388.html

[kqueue]

request rate is not influenced much by the polling mechanism (epoll/kqueue/poll/select) when all you're doing is listening to one fd and processing new ones then closing then immediately. These multiplexers matter when you are working on lots of file descriptors.

It matters because select will have to iterate over all the file descriptors you passed to it, while kqueue for example have knotes registered to it when it wakes up and won't need to iterate over everything, but just the knotes it got. Not to mention the data copying from userland to the kernel in case of select/poll.

Back to the request rate limitations, the limitation is mainly coming from the # of system calls you can execute in a sec (accept() in this case) which is heavily influenced by the context switches.

Looking at the application CPU gives you a very good idea of what your bottleneck is. If your CPU is 100% then it's clear your application is hitting the limit, but if the application CPU is at 30% and you cannot process more requests / sec then you've hit the system limit here.

[willvarfar]

Right, there is indeed a mode switch to read/write from/to the tcp buffer or accept a connection. Luckily mode switches are not context switches - which are typically massively more expensive - as only one thread is ever involved.

Hellepoll uses 'epoll' which is the Linux equivalent of kqueue. Kqueue is said to be marginally faster still, and I look forward to Hellepoll using kqueue when running on FreeBSD. Epoll/kqueue absolutely affect accept rate incidentally, so its an exercise to the reader to work out why ;)

Hellepoll does use the fanciest features of epoll like 'edge triggering' which is perhaps one of the things making it nudge ahead of Java's NIO-based webservers (as NIO is lowest-common-denominator and lacks ET).

Finally, Hellepoll is really writing meaningful bytes, and it even flushes them in keep-alive connections (obviously; think how it would ever work otherwise?).

So I think, on balance, Hellepoll is the real thing and not just measuring how quickly a big backlog on a listening socket can fill up ;)

On Linux, I've found the new 'perf timechart' a lot of fun.

[kqueue]

Network IO, Disk IO, scheduling, locks etc.. all trigger context switches and not only mode switch because only the kernel is allowed to manipulate data structures related to mbufs, vfs, and whatnot.

When I said epoll/kqueue doesn't affect the accept rate, I was replying back to a specific request of writing a program to just accept/reply/shutdown. In this case you are passing one fd to the poller which won't matter much what poller you are using.

My original comment is that you are measuring the wrong thing and it's not against hellepoll. requests / sec can be much higher than reply / sec because they get buffered waiting for you to accept them. Once accepted, then a request is counted. What matters though, especially to the http client is how long it takes to serve the connection from start to finish, hence reply rate.

fyi, you can use libev for poller portability.

You can experiment with this command and look at the reply rate.

httperf --num-conns=10000000 -vv --num-calls=1 --port=<your_port>