Version 2.2 – May 14, 2009
- Refined the check for ip address and port
- Changed the precision of the seconds reported
- Added column to report maximum operations per response time
- Added total display for all responses exceeding limit option “-d”
Version 2.0 – March 25, 2009
- Added check for wrapped log files. Don’t crash when it’s wrapped
- Added support for DoExtended… used with nmas for eDir updates
- Corrected -d statement in help screen
- Added check for Failed bind and Invalid Context during Bind. Reported in stats and CSV
- Added check for expired passwords. Reported in stats and CSV
- Added support for DoCompare LDAP operation
ldapconnresponse.pl [options] tracefile
Measure total connection time, from ‘New Connection to UnBind’ and also measure times between connection start and other LDAP operations.
This utilty serves a different purpose to elapse – it’s completely different. With elapse you measure only individual LDAP operations. What this script does is measure the entire LDAP transaction, which IS made up of multiple LDAP operations, e.g. Bind, Search & Unbind ..or.. Bind, Search, Search, Modify & Unbind
If you’re measuring LDAP performance you must use this util -elapse will not help you locate the root cause of slow LDAP transactions. Using this script we were able to show that slow transactions were due to client side code, for example. This is observed when firstly identifying which transactions are slow, then looking at what the dstrace shows for that specific transaction – multiple LDAP oprtations. Is the delay while waiting for the response to a request or between requests? This is the question which needs to be answered.
Also found that when using SSL, there is sometimes a delay between the initial connection and the Bind, indicating that the SSL handshake is slow. This can occur even when the LDAP operations per second being handled by the server is low, <30/sec.
Linux is super fast! If you’re using NetWare to handle a large number of LDAP operations check out Linux as an option – there is no comparison. Not only does the LX server handle a lot more user load, but backups and other file system activity is hugely faster. Overall it’s the way to go.
When no switches are supplied statistics are reported – try it with and without switches:
-x CSV output The CSV column 'New to UnBind' reports total connection time -d Total connection time is greater than this x seconds (0 displays all) -b object RDN (e.g. bsmith or "") -n Consecutive delayed connection responses (default 3) i.e. Based on value '-d', when do we see '-n' consecutive responses? Options -d -b [-n] should be used together *- Legend -* Identifies last LDAP operation performed on a connection: S = Search M = Modify A = Add D = Delete B = Bind R = ModRDN X = Abandon In Statistics View the symbols only provide some indication of (primary) operation Type verse Response: e.g. 'B' means only a Bind & Unbind occurred on a connection e.g. 'M' means a Modify occurred (many other ops could have preceded it) In CSV output the symbols indicate all operations for a specific connection!
Trace Configuration Options:
* Enable these LDAP Server Screen Options for trace analysis: + Critical Error Message + Non-critical Error Messages + Informational Error Messages + Connection Information + Additional connection and operation information in (hex format) * Enable these ndstrace/dstrace filters: +time +tags +ldap
Message to customers:
Please leave feedback and an email address if you can’t get this script to work. I’ll get back to you promptly. Ideally I need a copy of the dstrace so I can reproduce the issue, unless it’s simply a cause of command line parameters or sequence.