---- START access-control.html ---- ---- END access-control.html ---- ---- START appendix-changes.html ---- 87c87 <

That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and HEAD). Toward the latter end of the "Cached Search Performance" chart it gets hard to see the difference because the run times are so small, but the new code is about 25% faster than 2.3, which was about 20% faster than 2.2, which was about 100% faster than 2.1, which was about 100% faster than 2.0, in that particular search scenario. That test basically searched a 1.3GB DB of 380836 entries (all in the slapd entry cache) in under 1 second. i.e., on a 2.4GHz CPU with DDR400 ECC/Registered RAM we can search over 500 thousand entries per second. The search was on an unindexed attribute using a filter that would not match any entry, forcing slapd to examine every entry in the DB, testing the filter for a match.

--- >

That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and CVS HEAD). Toward the latter end of the "Cached Search Performance" chart it gets hard to see the difference because the run times are so small, but the new code is about 25% faster than 2.3, which was about 20% faster than 2.2, which was about 100% faster than 2.1, which was about 100% faster than 2.0, in that particular search scenario. That test basically searched a 1.3GB DB of 380836 entries (all in the slapd entry cache) in under 1 second. i.e., on a 2.4GHz CPU with DDR400 ECC/Registered RAM we can search over 500 thousand entries per second. The search was on an unindexed attribute using a filter that would not match any entry, forcing slapd to examine every entry in the DB, testing the filter for a match.

---- END appendix-changes.html ---- ---- START appendix-common-errors.html ---- ---- END appendix-common-errors.html ---- ---- START appendix-configs.html ---- ---- END appendix-configs.html ---- ---- START appendix-contrib.html ---- ---- END appendix-contrib.html ---- ---- START appendix-deployments.html ---- ---- END appendix-deployments.html ---- ---- START appendix-ldap-result-codes.html ---- ---- END appendix-ldap-result-codes.html ---- ---- START appendix-recommended-versions.html ---- ---- END appendix-recommended-versions.html ---- ---- START appendix-upgrading.html ---- ---- END appendix-upgrading.html ---- ---- START autoconf.html ---- ---- END autoconf.html ---- ---- START backends.html ---- ---- END backends.html ---- ---- START config.html ---- ---- END config.html ---- ---- START copyright.html ---- 27c27 <

--- >

37c37 <

--- >

---- END copyright.html ---- ---- START dbtools.html ---- ---- END dbtools.html ---- ---- START glossary.html ---- 1344c1344 < CVS --- > Cyrus 1347c1347 < http://www.cvshome.org/ --- > http://cyrusimap.web.cmu.edu/generalinfo.html 1352c1352 < Cyrus --- > Cyrus SASL 1355c1355 < http://cyrusimap.web.cmu.edu/generalinfo.html --- > http://asg.web.cmu.edu/sasl/sasl-library.html 1360c1360 < Cyrus SASL --- > Git 1363c1363 < http://asg.web.cmu.edu/sasl/sasl-library.html --- > http://git-scm.com/ ---- END glossary.html ---- ---- START index.html ---- 26c26 <

24 November 2011

--- >

12 February 2012

---- END index.html ---- ---- START install.html ---- 71c71 <

The configure script will also look at various environment variables for certain settings. These environment variables include:

--- >

The configure script also looks for certain variables on the command line and in the environment. These include:

73c73 < Table 4.1: Environment Variables --- > Table 4.1: Variables 124c124 <

Now run the configure script with any desired configuration options or environment variables.

--- >

Now run the configure script with any desired configuration options or variables.

126c126 < [[env] settings] ./configure [options] --- > ./configure [options] [variable=value ...] 132c132 <

However, this will fail to locate dependent software not installed in system directories. For example, if TCP Wrappers headers and libraries are installed in /usr/local/include and /usr/local/lib respectively, the configure script should be called as follows:

--- >

134,135c134,136 < env CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" \ < ./configure --enable-wrappers --- > ./configure --enable-wrappers \ > CPPFLAGS="-I/usr/local/include" \ > LDFLAGS="-L/usr/local/lib -Wl,-rpath,/usr/local/lib" 137,139d137 <

< Note: Some shells, such as those derived from the Bourne sh(1), do not require use of the env(1) command. In some cases, environmental variables have to be specified using alternative syntaxes. <

---- END install.html ---- ---- START intro.html ---- ---- END intro.html ---- ---- START license.html ---- ---- END license.html ---- ---- START limits.html ---- ---- END limits.html ---- ---- START maintenance.html ---- ---- END maintenance.html ---- ---- START monitoringslapd.html ---- ---- END monitoringslapd.html ---- ---- START overlays.html ---- ---- END overlays.html ---- ---- START preface.html ---- 26c26 <

--- >

---- END preface.html ---- ---- START quickstart.html ---- ---- END quickstart.html ---- ---- START referrals.html ---- ---- END referrals.html ---- ---- START replication.html ---- 72c72,75 <

Delta-syncrepl, a changelog-based variant of syncrepl, is designed to address situations like the one described above. Delta-syncrepl works by maintaining a changelog of a selectable depth on the provider. The replication consumer checks the changelog for the changes it needs and, as long as the changelog contains the needed changes, the consumer fetches the changes from the changelog and applies them to its database. If, however, a replica is too far out of sync (or completely empty), conventional syncrepl is used to bring it up to date and replication then switches back to the delta-syncrepl mode.

--- >

Delta-syncrepl, a changelog-based variant of syncrepl, is designed to address situations like the one described above. Delta-syncrepl works by maintaining a changelog of a selectable depth in a separate database on the provider. The replication consumer checks the changelog for the changes it needs and, as long as the changelog contains the needed changes, the consumer fetches the changes from the changelog and applies them to its database. If, however, a replica is too far out of sync (or completely empty), conventional syncrepl is used to bring it up to date and replication then switches back to the delta-syncrepl mode.

> Note: since the database state is stored in both the changelog DB and the main DB on the provider, it is important to backup/restore both the changelog DB and the main DB using slapcat/slapadd when restoring a DB or copying it to another machine. >

---- END replication.html ---- ---- START runningslapd.html ---- ---- END runningslapd.html ---- ---- START sasl.html ---- ---- END sasl.html ---- ---- START schema.html ---- ---- END schema.html ---- ---- START security.html ---- ---- END security.html ---- ---- START slapdconf2.html ---- 154c154 < trace function callss --- > trace function calls ---- END slapdconf2.html ---- ---- START slapdconfig.html ---- ---- END slapdconfig.html ---- ---- START tls.html ---- ---- END tls.html ---- ---- START troubleshooting.html ---- 64c64 <

bugs in released versions that are no longer present in HEAD code, either because they have been fixed or because they no longer apply, will not be considered as well; --- >

bugs in released versions that are no longer present in the Git master branch, either because they have been fixed or because they no longer apply, will not be considered as well; ---- END troubleshooting.html ---- ---- START tuning.html ---- ---- END tuning.html ----