Sébastien Arnaud wrote:
This is great news as well! Actually Apple released 10.4.3 today and
the kqueue bug is gone!!! Performance of the OS are actually up a
notch as well (~10% as far as cherokee is concerned). On my machine
benchmarking the small default cherokee page at 10 concurrency gives
me now 3.3K req/s with kqueue (and no errors!), and 5.6K req/s with
poll!
Anyway, I am glad to see that Apple fixed the problem with kqueue. I
am wondering though why kqueue is leading to such poor performance
when in theory it should yield to better performance than poll...
Maybe a little bit more in depth benchmarking might be able to see
the short fall of poll versus kqueue if in fact it is true under very
high concurrency/heavy load.
Hi Sébastien,
glad to hear about the Mac OS X kqueue fix.
The actual implementation of kqueue support for Cherokee performs more
than two kevent calls, one everytime there is a transition from
read->write or write->read in the socket (_set_mode() ), and one in the
_watch() function to get the status of the file descriptors.
My idea is to remove the one in _set_mode() and do only one in _watch().
The problem now is that if I do not inform to kqueue that I am not
interested any longer in one special event kqueue will keep informing of
them.
That shouldn't be a problem in a scenario in which the keep-alive is not
used, but if keep-alive is used it is very probable that when the server
switches the socket from read to write to process a request, there will
still be some data to be read in the socket (from the next request) this
will make that kevent will not sleep during the next calls because there
is activity in the socket, but as the server is not interested in that
the event will be ignored, and kevent will be called again and the same
process will happen again, making the CPU to burn ;-)
There is a solution, and that is to add to the change list a disable
request for the reads on a fd when switching to writes, and viceversa,
before adding one to register the new interest.
The good news is that I can reduce the number of kevent calls and that
should provide a performance increase, but if with only one kevent call
still performs worst that poll I don't think there will be much room for
improvement, but, I think if you have many file descriptors per thread
and a heavy load in the server, kqueue has a chance to perform better
than poll (better scalability)
I will try to rewrite the code as soon as I can, but I have a deadline
this week for the project I am working on, and I will be travelling in
the begining of next week so I don't think I will have a new
implementation before the end of next week.
Regards,
Rodrigo
_______________________________________________
Cherokee mailing list
[email protected]
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
