2.6.1 Logging

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

The log4j configuration settings are contained in a file called

Near the bottom of the jboss-log4j.xml file, look for the following entry:

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

Assigning a value to 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 set that threshold to ERROR, WARN, or FATAL unless 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 are well-known and are Apache log4j issues, not Identity Manager issues.

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 jboss-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.6.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 object class types and new attributes pertaining to the User Application. User-application-specific attributes are by default not indexed. For better performance, you might find it useful to index some of those attributes (and perhaps a few traditional LDAP attributes as well), particularly if your user container contains over 5,000 objects.

The general idea is to index only those attributes that you know are regularly queried, which could be different attributes in different production environments. The only way to know which attributes are heavily used is to collect predicate statistics at runtime. The collection process itself degrades performance, however.

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

If you already know which attributes you want to index, there is no need to use ConsoleOne. You can create and manage indexes in iManager with eDirectory Maintenance > Indexes. For example, if you know that users of your org chart are likely to 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 “Tuning eDirectory” in Novell’s Guide to Troubleshooting eDirectory by Peter Kuo and Jim Henderson (QUE Books, ISBN 0-7897-3146-0).

Also read about performance tuning in “Maintaining Novell eDirectory” in the eDirectory Administration Guide.

2.6.3 JVM

The amount of heap memory allocated to the Java virtual machine can impact performance. If you specify minimum or maximum 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.

For a JBoss server, you can set the maximum JVM^* size 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 might be needed to determine the optimal setting for your particular environment.

2.6.4 Session Time-out Value

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

Consider the following when adjusting the session time out:

Your application server might provide a way to specify session time out. Alternatively, you can adjust the session time-out value by opening the IDMProv.war archive, finding the web.xml file inside it, and editing 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, save the file and the archive, and restart the server.

2.6.5 Tuning JBoss

By default, the JBoss deployment scanner runs every five seconds. For a production server, this is typically not necessary and might impact performance. You should consider changing the scan period so that the deployment scanner runs less frequently, or turn the deployment scanner off entirely. For information about configuring the deployment scanner, see ConfiguringTheDeploymentScannerInConfjbossSystem.

For more information about tuning JBoss for production environments, see JBossASTuningSliming.

2.6.6 Using Secure Sockets for User Application Connections to the Identity Vault

By default, secure sockets are used for communication between the User Application server and the Identity Vault. However, in some environments, not all communication needs to be secured. For example, if the User Application and Identity Vault servers are on an isolated network, and the only ports available to the outside are the HTTP ports, it might be acceptable for some communication between the two servers to be accomplished using non-secure sockets. Some aspects of the application will always use a secure connection (for example, a user changing a password) even though the setting might indicate that secure connections are not required. Turning off secure connections, especially for user connections, can greatly increase performance and scalability. If, in a particular environment, there are many concurrent logins, and communication between the User Application server and the Identity Vault server have been secured using the network setup, then turning off the secure connection for user connections greatly increase the number of concurrent logins that can be processed. We recommend that this option be used only when there is actual evidence of scaling or performance problems in the environment, and adding additional eDirectory servers is not an option.

Additionally, secure connections can be turned off for administrative connections. These connections are used for general queries on the Identity Vault server that do not require user credentials. These connections are pooled and used round-robin. The bind over a secure connection is only done once at application startup (or possibly again later on if the connection becomes unresponsive) and so does not represent the scalability issues that can arise with the user connections. However, the time it takes to encrypt and decrypt the data at both ends does add overhead. We recommend that the default setting be used, unless there is a need to gain extra performance.

Secure communications for administrative and user connections must be disabled in both the User Application and in iManager. To disable secure communications for administrative and user connections, see the following topics: