9.3 Ensuring Concurrent Access from Multiple Clients

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 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:

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: