2.3.1 Logging

The user application allows logging via Novell Audit as well as via the open-source Apache log4j framework. Logging via Novell Audit is turned off by default. However, file and console logging via log4j are enabled by default.

The log4j configuration settings are contained in a file called log4j.xml under $IDMINSTALL/jboss/server/IDMProv/conf/. Near the bottom of this file, you will find the following entry:

<root>
    <priority value="INFO" /> 
      <appender-ref ref="CONSOLE" /> 
      <appender-ref ref="FILE" /> 
  </root>

Assigning a value to the root ensures that any log appenders that do not have a level explicitly assigned inherit the root level (in this case, INFO). For example, by default, the FILE appender does not have a threshold level assigned and so it assumes the root’s.

The possible log levels used by log4j are DEBUG, INFO, WARN, ERROR, and FATAL, as defined in the org.apache.log4j.Level class. Inattention to the proper use of these settings can be costly in terms of performance.

A good rule of thumb is to use INFO or DEBUG only when debugging a particular problem.

Any appender included in the root that does have a level-threshold set, should have that threshold set to ERROR, WARN, or FATAL unless (as just explained) you are debugging something.

The performance hit with high log levels has less to do with verbosity of messages than with the simple fact that console and file logging, in log4j, involve synchronous writes. An AsyncAppender class is available, but its use does not guarantee better performance. The issues (which are well-known and are Apache log4j issues, not Identity Manager issues) are set forth at http://logging.apache.org/log4j/docs/api-1.2.8/org/apache/log4j/performance/Logging.html.

The default of INFO in the user application’s log config file (above) is satisfactory for many environments, but where performance is critical, you should consider changing the above log4j.xml entry to:

<root>
      <priority value="ERROR"/>
      <appender-ref ref="FILE"/>
</root>

In other words, remove CONSOLE and set the log level to ERROR. For a fully tested/debugged production setup, there is no need to log at the INFO level, nor any need to leave CONSOLE logging enabled. The performance payoff of turning these off can be significant.

For more information on log4j, consult the documentation available at http://logging.apache.org/log4j/docs.

For more information on the use of Novell Audit with Identity Manager, consult the Novell Identity Manager Administration Guide.

2.3.2 Identity Vault

LDAP queries can be a bottleneck in a heavily utilized directory-server environment. To maintain a high level of performance with large numbers of objects, Novell eDirectory (which is the basis of the identity vault in Identity Manager) records frequently requested information and stores it in indexes. When a complex query is run against objects with indexed attributes, the query returns much faster.

Out of the box, eDirectory comes with the following attributes already indexed:

Aliased Object Name
cn 
dc 
Equivalent to Me
extensionInfo
Given Name 
GUID 
ldapAttributeList 
ldapClassList
Member
NLS: Common Certificate
Obituary
Reference
Revision
Surname 
uniqueID 
uniqueID_SS 

When you install Identity Manager, the default directory schema is extended with new objectclass types and new attributes pertaining to the user application. User-application-specific attributes are (by default) not indexed. For better performance, you may find it useful to index some of those attributes (and perhaps a few traditional LDAP attributes as well), particularly if your user container will contain over 5,000 objects.

The general idea is to index only those attributes that you know will be regularly queried. (Which could very well be different attributes for different production environments.) The only way to know for sure which attributes are heavily used is to collect predicate statistics at runtime. (The collection process itself is performance-degrading, however.)

The process for collecting predicate statistics in discussed in detail in the eDirectory Administration Guide. Indexing is also discussed in more detail there. In general, you will need to do the following:

If you already know which attributes you want to index, there is no need to use Console One. You can create and manage indexes in iManager via eDirectory Maintenance > Indexes. For example, if you know that users of your org chart will very likely perform searches based on the isManager attribute, you can try indexing that attribute to see if performance is enhanced.

For an in-depth discussion of attribute indexing and performance, see the chapter on “Tuning eDirectory” in Novell’s Guide to Troubleshooting eDirectory by Peter Kuo and Jim Henderson (QUE Books, ISBN 0-7897-3146-0).

Also see the chapter on “Maintaining Novell eDirectory” (which has performance-tuning guidance) in the main eDirectory Administration Guide.

2.3.3 JVM

The amount of heap memory allocated to the Java virtual machine can impact performance. If you specify min or max memory values that are either too low or too high (too high meaning more than the physical memory of the machine), you could experience excessive pagefile swapping.

You can set the max JVM size for the JBoss server by editing the run.conf or run.bat file (the former for Linux, the latter for Windows) under [IDM]/jboss/bin/ in a text editor. Increase “-Xmx” from 128m to 512m, or possibly higher. Some experimentation may be needed to determine the optimal setting for your particular environment.

2.3.4 Session Timeout Value

The session timeout (the amount of time a user can leave a page unattended in his or her Web browser before the server causes a session-timeout warning dialog to appear) can be changed in the web.xml file in the IDM.war archive. This value should be tuned to match the server and usage environment in which the application will run. In general, it is advised that the session timeout be as small as practicable If business requirements can tolerate a 5-minute session timeout, this would allow the server to release unused resources twice as early as it would if the timeout value were 10 minutes. This makes the Web application more performant and scalable.

Please consider the following when adjusting the session timeout:

To adjust the session timeout value, you will need to open the IDM.war archive, find the web.xml file inside it, and edit the following portion of that file (in particular, the numeric value, shown here as 20, meaning 20 minutes, which is the default):

<session-config>
    <session-timeout>20</session-timeout> 
</session-config>

Then you will need to save the file and the archive, and restart the server.