github.com
The project died, but I'm glad I get to share the a basic version with some http test code now.
I admit this is the second time I've tried to show this off here today; I posted earlier but it got lost when no-one was watching :(
#ifdef __cplusplus
extern "C" {
#endifWindows porters frequently have to do this to deal with the fact Microsoft still refuses to produce a C compiler, and instead just does double duty on their existing C++ compiler.
http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx...
if buf[i:i+4] == "POST":
Nginx is not tornado in c. Its not about complex custom logic, its about rules redirects and caching.
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
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.
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.
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>
2) ab does wait for the requests to complete before sending the next
3) you really are flat wrong when you don't make a distinction between mode switching and context switching
4) conclusion: with a name like yours, you must be trolling
Go read your OS book.
I am not trolling. you just lack experience and this sounds new to you.
I've asked around a bit and am fairly sure of my facts again, and my understanding is:
* kernel mode is cheaper than ever to reach; SYSCALL/SYSENTER etc so its not even an interrupt and there are no hardware threads or anything involved
* in kernel mode, the thread can get straight at the buffer and the locks that protect it; there is nothing that we'd call a 'context switch' in there
* being as this seems to be what is meant by monolithic kernel, surely its the same on freebsd too?
When you make a system call, a trap is issued that causes the hardware switch to kernel mode.
The hardware pushes onto the per-process kernel stack the pc, status word, and the kernel code takes care of saving the registers, esp, etc.. this is called a task context switch. Context switching between processes is much more expensive but task context switching is still considered a context switch.
When you are making a system call, it's still much more expensive then most of the work you are doing in your program hellepoll and hence it's your bottleneck. This is why you don't see your process's CPU at 100%.
On a related note, whenever you have a program doing a lot of network IO, you are essentially causing a lot of process context switches because each time you get data on the wire you cause a context switch because the kernel needs to handle this hardware interrupt.
Yes, to get these numbers i have had to minimise syscalls. Thats the advantage of hellepoll. I wrote the http server just to release it, as before it was an rtmp server but it was commercial and couldn't be released. That had write buffers usr side too which helped even more.
And i understand what ab and httperf test, and yes i am counting served pages.
Finally, i spend a lot pf time staring at linux perf reports and timecharts.