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!

Note: An Abandon operation is seen as a result of a failed Bind or when an LDAP operation response times exceeds the maximum time (passed to the operation as a parameter)

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.



Comment List
  • Haven't tried it on windows. The determining factor will be the output, if it's not text, like that provided by NW and LX, then it won't work. Saving HTML output as text might work... but I haven't tried this. Limiting factor would be the file size. To get good stats you need large files, ideally, e.g. 30-60 mins of data... which might be 50-100mb. Activeperl is what I use on Windows.

    Apologies for the late rely... I don't normally think to check for comments. Will do in future.
  • Does this work with edirectory on Windows? I assume just need perl installed on Windows server.