Version 2.2 - May 14, 2009

Changes:

• 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

Changes:

• 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

Syntax:

 ldapconnresponse.pl [options] tracefile

Purpose:

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.

Options:

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.