In a medium to large environment, you might have 50 or more clients accessing the server concurrently. To prevent operational failures, configure the following settings:
The session time out represents the amount of time users can leave a page unattended in their web browser before the server displays a session-time-out warning. You must tune this value to match the server and usage environment in which the application runs. In general, the session time out should be as short as practicable. If a 5 minute time out does not impact your business, this time period would allow the server to release memory twice as early as it would if the time-out value were 10 minutes. This improves the performance and scalability of the web application.
You can define time out for web application, LDAP, and Tomcat sessions. In Identity Applications, only LDAP and web application session time outs are used.
The web application session time out value is represented by the com.netiq.idm.session-timeout property in the ism-configuration.properties file. The default value is 1200 seconds.
The LDAP session time out value is represented by the com.novell.ldap.timeout property in the ism-configuration.properties file. The default value is 600000 milliseconds.
The Tomcat session time out represents the amount of time Tomcat retains the information pertaining to a user's session, when the user does not perform any action on the web page. All Tomcat servers provide a default web.xml file in the tomcat_home/conf/ directory. To configure the session time out globally for the entire web server, locate the <session-config> configuration setting and change the value of the session-timeout tag. The Tomcat session time out value is overwritten by the web application session time out value for every user session.
The default time out values for a web application, Tomcat, and LDAP sessions are different. They need not be same. For example, a user needs more time on the Identity Applications user interface than a query that is issued to retrieve information from the Identity Vault.
Consider the following points when adjusting the session time out:
Long session time-outs can cause the Tomcat server to run out of memory if many users log in for a short period. This is valid for application server that has too many open sessions.
For example, if the session time out value is 10 minutes and approximately 10 users log in per minute and those users are idle and do not log out during this time, you are likely to have 100 concurrent users at any point in time. If a single user consumes 1 MB of heap, 100 MB of memory is used by those idle users. When the maximum time out value is reached, the idle users need to log in again to use the application. If a query is in progress and it hits the maximum time out value, the query is stopped. You must log in again for the query to continue.
The recommended value is 3 to 5 minutes.
When a user logs in to Identity Applications, an LDAP connection is created for the user and the user is 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.
In addition to a short time out interval, increase the number of open files on the Linux server. If you exceed the open file limit, check your catalina.out logs for errors. For more information, see Increasing the Number of Maximum Open Files.
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 modify the session time out after installation by changing this value in the web.xml file in the IDMProv.war archive followed by a configuration update.
Lowering the session time out quickly clears the LDAP connection threads, which improves performance.
If Tomcat reports the Too many open files exception when the number of concurrent logged-in users is large, consider increasing the limit of open files (ulimit –n) in the server.xml file depending on the concurrent sessions expected on the server. Ensure that the host operating system is able to handle the increase in the number of open files. For example, on a server with 100 concurrent connections, increase the number of open files to 10000.
Increase the number of user processes (ulimit –u) for the user that runs the Tomcat process on all Tomcat servers. For example, if you have 30000 concurrent connections, setting the number of user processes to 128502 works fine.
The configured connectors determine how browser and other clients access Identity Applications deployed on Tomcat. Tomcat 9 provides a default HTTPS connection, which leads to better thread management with longer running requests. The default maximum thread pool size within Tomcat 9 is 200.
Keep in mind that many active threads at the same time can slow down Identity Applications, and even the server hosting Identity Applications. Therefore, you must set the maximum number of threads that can be created to meet your requirements by using the maxThreads property in the server.xml file. For example, specify maxThreads="1000" for an https connector. On a computer with four processors, you can set this value between 800 and 1000. For example, set it to 800 if you expect a limited number of users to access the application and 1000 when a large numbers of users are anticipated to access the application. If the value exceeds the number of threads required, the thread pool shrinks as the volume decreases.
Connectors are configured by using the minProcessors, maxProcessors, acceptCount, and enableLookups properties in the server.xml file. Below is an extract of connector configuration from the server.xml file in which some of these properties are assigned specific values.
<Connector port="8090" maxHttpHeaderSize="8192" maxThreads="400" minSpareThreads="150" maxSpareThreads="300" connectionTimeout="2" acceptCount="50" maxKeepAliveRequests="400" disableUploadTimeout="true" />
The acceptCount property defines the number of pending requests awaiting processing by the server. By default, it is 10. You must change it when a high rate of incoming connection requests result in connection failures. For example, leave it at default if you expect a limited number of requests and change up to 50 to accommodate a large numbers of requests when several users access the application at the same time. However, setting it too high can overload Tomcat, which can cause problems for all requests.
Increase maxKeepAliveRequests if you have sufficient capacity. Using persistent connections improves performance and prevents wasting CPU resources in reestablishing HTTP connections.
If the system slows down with a high thread count, analyze the performance and thread usage under the anticipated usage load and then adjust the value. For example, to obtain the number of threads of a process, run grep Threads /proc/<PROCESS_PID>/status.If the workload of a single server is high, you can cluster the Tomcat instance to allow the thread pool to be virtually distributed across the nodes of the cluster. Each server in the cluster will need less within its thread pool.
For complete documentation of the HTTP Connector configuration, see http://tomcat.apache.org.
Identity Applications communicate with the database through a JDBC connection pool. A connection pool starts with a small number of connections. As clients demand for more connections increases, there may not be enough connections in the pool to satisfy the requests. The Tomcat server creates additional connections and adds them to the pool until the maximum pool size is reached.
For example, when multiple users access the Tasks page at the same time, Identity Applications connect to the User Application database and query for the task list. Tomcat allocates a resource from the database connection pool to make the connection with the database. When all connections are relatively busy and the connection pool is empty, Identity Applications wait until a connection is released.
To configure a JNDI data source that uses connection pooling in Tomcat, add the following ResourceLink global element in the conf/context.xml file:
<ResourceLink global="shared/IDMUADataSource" name="jdbc/IDMUADataSource" type="javax.sql.DataSource" />
In this example, the JNDI context is created with jdbc/IDMUADataSource name, which is a type of DataSource. The database configurations are defined in Tomcat’s server.xml file in the url, username, password, and driverClassName attributes. The connection pooling properties are defined in maxTotal(maxActive before Tomcat 8), maxIdle, and minIdle attributes.
Review the following while configuring the JDBC connection pool:
The number of concurrent tasks that will execute at the same time.
The other runtime components. Each runtime component works in conjunction with the other runtime components. NetIQ recommends setting the size of the initial connection pool to 10. To change it, modify the following entry in Tomcat’s server.xml file:
<Resource auth="Container" driverClassName="org.postgresql.Driver" factory="com.netiq.tomcat.jdbc.pool.CustomBasicDataSourceFactory" initialSize="10" maxActive="50" maxIdle="10" maxWait="30000" minIdle="10" name="shared/IDMUADataSource" password="srNOGbFupaKGrFfhULugQw==:KggiF61gvadcEpxqlCt5gQ==:yFZtb+h0bk5iQ7LUniIsRA==" testOnBorrow="true" type="javax.sql.DataSource" url="jdbc:postgresql://220.127.116.11:5432/idmuserappdb" username="idmadmin" validationInterval="120000" validationQuery="SELECT 1" />
The number of connections in the pool must allow each executing task to retrieve and update task and event data throughout the lifetime of the task.
The database uses prepared statements. You must configure the prepared statement cache for the database that you are using to store the data.