[Date Prev][Date Next]
--On Saturday, January 14, 2006 12:18 AM -0800 Quanah Gibson-Mount
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
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
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.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
- Re: ITS#3950
- From: Quanah Gibson-Mount <email@example.com>