On that note, has there been any evaluation of TCP_DEFER_ACCEPT,
TCP_CORK and/or splice() ?
Is this something that the httpd folks might have evaluated?
john
Anirban Kundu wrote:
We are going to run some in-house tests to see the throughput changes and the
CPU usage changes w/ and w/out EPOLLET. We'll publicize the results when we're
done w/ the tests.
-Anirban
On Nov 24, 2009, at 8:53 AM, Anirban Kundu wrote:
Hi John,
Your point is well taken.
Actually, there is a general mis-conception that putting EPOLLET automatically
makes the code faster. That is actually not true. The only reason you benefit
from EPOLLET, is because if you do miss reading the entire data from the sock
buffer, you dont constantly get pinged about something to read.
Theoretically, if your system is implemented correctly, as in read all the data
available from the network buffer (till you hit EAGAIN, or better yet less than
the amount you've asked to read), you really dont need to use EPOLLET.
There is a plan on removing EPOLLET from the system. One can achieve the same
system usage time, with and without EPOLLET.
-Anirban
On Nov 14, 2009, at 1:57 PM, John Plevyak wrote:
A couple things:
1. Current epoll seems to use EPOLLET in most cases (except for example the
initial DNS connection).
Is this required? It wasn't the case before and it isn't portable. Was it put
in for performance?
libev doesn't support EPOLLET because it isn't portable, and this requirement
would prohibit an
OSX port.
2. libevent is currently between the stable 1.X and a new 2.X-alpha with a new
API. It doesn't seem sensible
to either use the old API which is going away or use alpha code.
I thinking of wrapping the current epoll calls and data structures with an API
and try to make it as compatible
as possible with libev and the new libevent 2.0 API.
If I can get it in decent shape I'll circulate a patch.
john
