openldap-devel

openldap-devel@openldap.org

2 participants
1422 discussions

Move LDAP_DEVEL features into 2.4?
by Pierangelo Masarati 14 Oct '07

14 Oct '07

I have few enhancements that could go into 2.4 based on consensus. - BDB_MONITOR_IDX: monitor missing indices in searches. Let me remember that this feature allows to monitor (thru cn=Monitor) how many search candidate selections missed an index, and what index type. It costs a mutex lock/unlock for each call to bdb_index_param(). - pcache private database access: add a control and an exop that allow access to the private database for administrative/monitoring purposes, and consistent cached query removal (namely: removal of a specific query and related queryID from participating entries; removal of an entry and invalidation of all related queries, ...) Please comment. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 3

Monitoring slapd entities...
by Pierangelo Masarati 14 Oct '07

14 Oct '07

What back-monitor does in many cases is monitoring entities living inside slapd. In those cases, the living entity and back-monitor's entry should be in touch with each other to account for reciprocal updating. The flow of information, so far, has been handled in one direction by providing a neutral interface (actually, two): - the per-subsystem hooks - the callbacks Callbacks are much more general than per-subsystem hooks. I think per-subsystem stuff should be eliminated, as they basically duplicate callbacks with less flexibility. However, I believe bi-directional communication could make many things much easier. Let's think what operations may require either direction: back-monitor needs to be able to ask living entries information when it is asked to present entries (e.g. in response to a search). For this purpose, the current callback mechanism should be sufficient. However, living entities may need to contact back-monitor for many purposes: to register new callbacks, to add/remove themselves to/from back-monitor. For this latter purpose, a solution could be to augment all living entities with a pointer to their entry in back-monitor. This pointer should be set by back-monitor as soon as that entry is created. This would ease feature registration by acting as a key (the caller would finally know the real DN of its entry), rather than figuring out a mechanism to locate it as it is currently done by the monitor_back_register_* calls. Basically, BackendInfo, BackendDB, overlay_info and overlay_inst would need an (Entry * (*)_monitor) to their entry in back-monitor, to be mostly used as a key when calling monitor-related functions. Other structures in the future may need it, but the interface would be general enough to allow extensions. Comments? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 1

ITS#4787: Download links with version vs. date
by Michael Ströder 11 Oct '07

11 Oct '07

Hope it's ok to take this to openldap-devel. Kurt Zeilenga wrote: > ITS#4787: requests change in "stable" release naming. More discussion > needed. (I oppose making this change for various reasons). What are these "various reasons"? Ciao, Michael.

2 1

New performance numbers
by Howard Chu 11 Oct '07

11 Oct '07

Back in May 2006 we posted some authentication rate numbers for Symas CDS 3.3.2 (based on OpenLDAP 2.3.21.) http://connexitor.com/blog/pivot/entry.php?id=49 On a 1 million entry database, we saw about 13K auths/second on a dual processor 2.8GHz Opteron system. We've recently re-run the tests using OpenLDAP 2.4.5 on a dual processor 2.8GHz dual-core Opteron system (so, 4 cores now instead of just 2) and gotten 38K auths/second. One interesting thing to note is that we reached this same rate on back-bdb, with the slapd server at 100% CPU utilization, as well as with back-null, where slapd was only at 70% CPU. (This implies to me that there may have been a network bottleneck here, because we ought to have been able to drive slapd into 100% CPU usage even with back-null. Even gigabit ethernet has its limits...) But the other nice point about this result is that while the number of CPU cores was increased by a factor of 2, the overall auth rates increased by a factor of 2.7. So we can see that OpenLDAP 2.4 is at least 35% faster than OpenLDAP 2.3. It also shows that the lightweight dispatcher is still scaling well with available CPU power. Another point is the same thing I've harped on before - SLAMD is too inefficient on clients. We measured the 38K/sec rate using the slapd-auth C client that I just added to CVS HEAD. Using the SLAMD java client we could only reach 29K/sec, even with 12 client machines and 10 threads per client. Someone's going to have to sit down and write a C client that speaks the SLAMD server protocol and just fires off compiled C clients... -- -- 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/

3 3

Re: #15646 BerkeleyDB hybrid mutexes
by Howard Chu 10 Oct '07

10 Oct '07

Keith Bostic wrote: > On Oct 9, 2007, at 12:02 AM, Howard Chu wrote: > >> With a CPU-hog running in the background, the test with BDB 4.2.52 >> takes only 37 seconds, while BDB 4.6.21 takes 1:42. Watching with >> top you can see that BDB 4.6.21 gets a lot less CPU than BDB >> 4.2.52. This is the problem with using yield() on an NPTL system - >> whereas on most POSIX systems yield() only yields control to some >> other thread in the current process, on NPTL yield() gives up the >> CPU for the entire process. > > Is there a call that would be preferable on NPTL? > > What call on NPTL will only yield control from the thread, not the > entire process? When we first encountered this problem in the OpenLDAP source we used select() with a zero timeout. But I recall that that performed poorly as well, and nowadays we just avoid doing any type of yield at all. I think the real answer here is that on Linux 2.6 you really just want to use the native mutex (pthread, futex, whatever it's called) and not do anything else. -- -- 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/

1 0

back-ldap connection caching
by Howard Chu 10 Oct '07

10 Oct '07

After running SLAMD against back-ldap I've noticed some problems in the approach - while a single load generator may send multiple requests over a single connection, back-ldap always creates new connections for each incoming Simple Bind, and leaves them available to be shared by other sessions. Thinking about it, this usage doesn't really make a lot of sense. Any identity that's explicitly binding to back-ldap is necessarily going to be different from any other session's ID. The only sessions that it makes sense to share are those that were implicitly bound because they were authenticated elsewhere, and fell into this backend (via glue, typically) while processing some other request. So I think this means we should separate out the explicitly bound connections from everything else. They should only live as long as their inbound slapd connection lives, and should only be used by ops from their inbound slapd connection. -- -- 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/

2 3

#15646 BerkeleyDB hybrid mutexes
by Howard Chu 08 Oct '07

08 Oct '07

Fyi, hybrid mutex support in BDB 4.6.21 is still not a good idea on 2.6 Linux systems. -- -- 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/

2 1

slapo-memberof nested group behavior
by Faraz Khan 08 Oct '07

08 Oct '07

Dear all, i know that nested groups have been discussed in detail before- just wanted to know what the priority of implementing nested groups through slapo-memberof or otherwise is. The functionality already discussed is: If A memberof B and C memberof A then C memberof B Functionality required would be that the memberof attribute handles recursion correctly. The administrative importance of this functionality cannot be emphasized more upon. I am willing to help out with the slapo-memberof module if the functionality can be built into the current overlay only. Pointers on how to accomplish this would be appreciated. -- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.111.111.320 x200 www.emergen.biz

2 1

Old open bugs
by Howard Chu 08 Oct '07

08 Oct '07

I just noticed that ITS#4468 was fixed in 2.3.34 by the fix for ITS#4805. Hallvard, are you still tracking ITS#3864 and #4467? Ando, did fixes for ITS#4563 and 4591 ever get backported from HEAD into a release? -- -- 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/

2 2

Re: commit: ldap/build openldap.m4
by Gavin Henry 05 Oct '07

05 Oct '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/build > > Modified Files: > Tag: OPENLDAP_REL_ENG_2_3 > openldap.m4 1.140.2.13 -> 1.140.2.14 > > Log Message: > Reject BDB 4.6 or newer > Much easier than telling folks they can use the early version of 4.6 I think. -- 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/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel