icu -- is it the "recommended" OpenLDAP unicode implementation?
by Xin LI
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'd like to get an inquiry about the state of OpenLDAP's unicode
implementation. Recently there is some reports that the FreeBSD port of
OpenLDAP 2.4.x will pick up icu automatically if it is installed,
according to the configure script, it seems that there is no way to
disable this behavior (i.e. by --disable-icu or something similar), so
it seems that a patch will be necessary if the user does not want to use
icu.
So my question is that, is it recommended to use icu? I am thinking
about making icu an mandatory dependency of the port, but I guess it
would be good to ask the developers before making such changes :)
Cheers,
- --
Xin LI <delphij(a)delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQFHuP63i+vbBBjt66ARAiqcAKCuxW9xJW3qVataZpBeKVjBhbXHcQCffYy/
JhU4ZOghLdrGzYHTzQt7Ey8=
=xTGY
-----END PGP SIGNATURE-----
15 years, 1 month
Anyone use ccache?
by Gavin Henry
Just curious, does anyone use ccache when compile/developing etc.?
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
15 years, 1 month
RE23 testing
by Quanah Gibson-Mount
Please test RE23 in preparation for OpenLDAP 2.3.41.
Thanks,
Quanah+
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 1 month
Thread pool efficiency
by Howard Chu
Testing on an 8-socket AMD server with Opteron 885 dual-core processors (16
cores total) and a Sun T5120 (T2 Niagara 8 cores, 64 hardware threads) has
shown that our current frontend code is performing very poorly with more than
16 server threads.
E.g. on the AMD system with 16 cores allocated, performance was still slower
than on the 4-socket AMD server with Opteron 875 dual-core processors (despite
2x the cores and a significant clock-speed advantage). Testing also showed
that in this configuration, at least one of the 16 cores was always 100% idle.
Basically, the frontend cannot hand out work fast enough to the worker threads.
Rather than using a single mutex to control all accesses into the thread pool,
I think we need to have separate queues per worker thread. The frontend can
operate in single-producer mode where only the single listener thread is
allowed to submit jobs into the pool. The workers can just access their own
individual work queues, thus significantly reducing mutex contention.
Ideally we would arrange things such that any data structure is only ever
written by a single thread, and all other threads only perform reads against
it. (And in the best case, only one other thread needs to perform that read.)
By eliminating memory ownership changes and unnecessary cache line sharing, we
can dramatically reduce the cache coherency traffic.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 1 month
RE23 final call for testing
by Quanah Gibson-Mount
A few issues were identified in the last round of testing. If people could
test again with current RE23 CVS that would be much appreciated.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 1 month
RE24 final call for testing
by Quanah Gibson-Mount
A few issues were identified in the last round of testing. If people could
test again with current RE24 CVS that would be much appreciated.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 1 month
Re: thread pools, performance
by Howard Chu
Rick Jones wrote:
> There are definitely interrupt coalescing settings available with tg3-driven
> cards, as well as bnx2 driven ones:
>
> ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt
Yep, that helped. Raising rx-usecs from default 20 to 1000, and rx-frames from
default 5 to 100, I'm getting 43k auths/sec with back-null (in 4 separate
thread pools) and the core fielding the interrupts is only about 80% busy now
instead of 100%. I'm afraid my load generators may be maxed out now, because I
can't seem to drive up the load on the server any higher even though there's
more idle CPU.
The current code in HEAD (with only 1 thread pool) is reaching 36k auths/sec
with back-null, so it's actually not far off from my experimental peak rate.
Considering that HEAD was at 25k/sec last week (and now in 2.4.6) that's
pretty decent.
With back-bdb and 1 million users I'm getting 26.1k/sec with plaintext
passwords (up from 19.3k/sec last week). With {SSHA} passwords that drops to
25.7k/sec (~1.5% difference).
I have to put this tinkering on hold for a bit, to run some authrate tests
against ActiveDirectory on this machine (using W2K3sp2 X64). Later on we'll do
a W2K3 OpenLDAP build for comparison as well. Should be entertaining...
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 1 month
Re: RE24 testing
by Luca Scamoni
Passes on CentOS 4.6 and CentoOS 5.1 (i686 and virtual machines)
I had only one run in which test050 seemed to have been gone in a sort
of loop on a CentOS 4 VM, but I've not been able to reproduce it in more
than 20 runs of the test.
Ing. Luca Scamoni
Responsabile Ricerca e Sviluppo
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 0382 573859 (137)
Mobile: +39 347 1014425
Email: luca.scamoni(a)sys-net.it
-----------------------------------
15 years, 1 month
RE24 testing
by Quanah Gibson-Mount
Please test RE24 in preparation for 2.4.8.
Thanks,
Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 1 month
Re: commit: ldap/libraries/libldap_r tpool.c
by Hallvard B Furuseth
Howard, do you remeber if this was a bug fix or an optimization? If the
former it was merely triggering some other bug which can presumably
still happen due to spurious wakeups. Or if the problem is that the
cond can be destroyed at this point if the pool is tearing down, so can
the mutex - even though it is locked here.
At Thu, 18 Oct 2007, hyc wrote:
> tpool.c 1.80 -> 1.81
>
> In pool_resume don't touch the condvar if the pool is tearing down.
It's this patch to ldap_pvt_thread_pool_resume(), aka "pool_resume
fix from HEAD" in the CVS comment for import to RE24:
@@ -704,3 +704,4 @@
pool->ltp_pause = 0;
- ldap_pvt_thread_cond_broadcast(&pool->ltp_cond);
+ if (pool->ltp_state == LDAP_INT_THREAD_POOL_RUNNING)
+ ldap_pvt_thread_cond_broadcast(&pool->ltp_cond);
ldap_pvt_thread_mutex_unlock(&pool->ltp_mutex);
--
Hallvard
15 years, 1 month
