Performance tuning is a complex subject. The Identity Manager User Application relies on diverse technologies with many interactions. It is not possible to anticipate every single configuration scenario or user interaction scenario that could result in poor performance. Nevertheless, some subsystems are subject to best practices that can boost performance.
See the following sections for information:
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.
NOTE:The kinds of events you can log, and how to enable or disable logging, are covered in Section 3.0, Setting Up Logging.
The log4j configuration settings are contained in a file called
jboss-log4j.xml in the install directory (if you are using a JBoss application server)
log4j.xml in the User Application WAR (if you are using a non-JBoss application server)
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.
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:
Use ConsoleOne® to turn on predicate-statistics collection for attributes of interest
Put the system under load
Disable statistics collection and analyze the results
Create an index for each type of attribute that might benefit from having one
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. 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.
NOTE:As a best practice, it is recommended that you index, at a minimum, the manager and isManager attributes.
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.
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 from 128m to 512m, or possibly higher. Some experimentation might be needed to determine the optimal setting for your particular environment.
NOTE:JBoss and Tomcat performance tuning tips are at http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossASTuningSliming
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:
Longer session time-outs can cause the JBoss server to run out of memory if many users log in over a short period of time. This is true of any application server that has too many open sessions.
When a user logs in to the User Application, an LDAP connection is created for the user and bound to the session.Thus, the more sessions that are open, the greater the number of LDAP connections that are held. The longer the session time out, the longer these connections are held open. Too many open connections to the LDAP server (even if they are idle) can cause system performance degradation.
If the server starts experiencing out-of-memory errors, and the JVM heap and garbage collection tuning parameters have already been optimally tuned for the server and usage environments, consider lowering the session time out.
You can set the session time out value on the User Application Configuration screen at installation time. Alternatively, you can modify the session time out after installation by performing a configuration update.
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.
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:
To disable the secure administrative and user connections in the User Application:
Run the configupdate script, located in the User Application directory, as follows:
Linux: Type the following to run configupdate.sh:
Windows: Run configuupdate.bat
The User Application configuration utility starts.
To disable the requirement for secure LDAP (LDAPS) connections for administrative and user connections to eDirectory using iManager or ConsoleOne:
Log into your eDirectory tree.
Navigate to thegroup object and display its properties.
NOTE:In a multi-server eDirectory tree, disabling TLS on the LDAP group removes the TLS requirement from all servers. If you want mixed TLS requirements for each individual server in your tree, you must enable the TLS requirement on each server.