[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS#3950



--On Saturday, January 14, 2006 12:18 AM -0800 Quanah Gibson-Mount <quanah@symas.com> wrote:

Here is a further update. 

First, I note that the above tests, and the following, were all done on a
Linux 2.4 kernel.  I believe the REPLACE_BROKEN_YIELD bit *must* be
disabled for 2.4 kernels.

The results from a full throttle test of 2.3.17 on the linux 2.4 kernel:

REPLACE_BROKEN_YIELD, NANOSLEEP = 535 searches/second average
REPLACE_BROKEN_YIELD, SELECT = 4706 searches/second average
UNDEF REPLACE_BROKEN_YIELD = 8138 searches/second average (and I believe
I maxed out my 100MB/s ethernet here, possible it could be higher
otherwise)


Here are some more statistics, gathered on the same machine, only running a 2.6.8-2 kernel (latest I have available atm). OpenLDAP was compiled fresh for each configuration on the 2.6 kernel (to ensure correct EPOLL detection).

B = Broken
N = Nanosleep
E = EPoll
R = Rate

If there is an X in the B/E/N column, it is defined.


B N E R

X X X 5,726.250 searches/second
X X   5,626.316 searches/second
X   X 5,637.446 searches/second*
X     5,764.666 searches/second*
 X X 7,987.427 searches/second
 X   8,356.041 searches/second

* - These rates had a very spiky graph, i.e., the rate at any given time slice was wildly varying. The other search sets were relatively smooth.


Generally, what is indicated here, is that BROKEN being undefined, and EPOLL undefined, is the best option, at least for this 2.6 kernel. All of the BROKEN defined set are substantially slower than not having BROKEN defined. UNDEFing Nanosearch makes the OpenLDAP rate behavior vary wildly in any given second.

I also note that the 2.4 build that resulted in 8,138 searches/second last night resulted in a search rate of 8,414.434 searches/second when ran on the 2.6 kernel.

--Quanah


--
Quanah Gibson-Mount
Product Engineer
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>