Tuning Apache Tomcat

This topic contains information about tuning Apache Tomcat, which is used for Siebel Application Interface and for the application container for Siebel Server and Siebel Gateway.

The following table describes settings that might be appropriate for Apache Tomcat, given different frequencies of login activity.

Login Frequency	Low	Medium	High
Apache Tomcat heap size for Siebel Application Interface and Siebel Gateway	4 GB	8 GB	12 GB
maxThreads	200 or more	500 or more	2000 (recommended)

Low login frequency is characteristic of employee-facing applications that support no more than 6,000 users and experience no more than 1,000 logins or logouts per hour. Employee users might typically log in once for several hours before logout. Such deployments might typically experience a low-frequency mix of Siebel EAI and customer logins.
Medium login frequency is characteristic of applications that support more than 6,000 users and experience 1,000 to 10,000 employee logins or logouts per hour. Such deployments might require additional instances of Siebel Application Interface and deployment of Siebel Gateway clustering.
High login frequency is characteristic of applications that experience more than 10,000 logins and logouts per hour. Such deployments would require additional instances of Siebel Application Interface and deployment of Siebel Gateway clustering

Note: To avoid a single point of failure, all Siebel CRM deployments must have at least two Siebel Application Interface nodes and three Siebel Gateway (ZooKeeper) nodes, which provides high availability across these tiers. For medium and high login frequency, it is recommended to have five or more Siebel Application Interface nodes and five or more Siebel Gateway nodes, depending on the workload.

The values shown in the table are estimates and depend on many factors including the duration of each login request, login storms, frequent incoming EAI requests that each require a new login, and so on. Thorough scalability and performance testing in production-like conditions is strongly recommended to find the right settings. Add more servers, as needed, based on close monitoring. While performance issues are under investigation, frequent restarts are recommended to mitigate performance degradations.

In general, the value of maxThreads is based on the number of expected login requests per second for this instance of Tomcat, and on the average length of time required to process a request. For example, if about 2,500 requests per second are expected, and each request takes about 200 milliseconds to process, then this means that about 500 requests must be processed during a given second: 2,500 times (200 ms divided by 1000 ms) = 500. With a buffer included, you might set maxThreads to about 550.

You can configure a higher throughput if you have a multiple-processor CPU. However, the benefit is partly offset by the CPU spending more time in managing threads, context switching, and application demands of threads than processing login requests, particularly during periods of heavy server load. Using multiple load-balanced Apache Tomcat instances is a more efficient way to be able to process more threads per second. Test any configuration before deploying it for production environments.

Note: If login requests are not able to obtain threads for processing, then, before increasing the maxThreads setting, check if, for a given request, modules like the Application Object Manager or the Siebel database are taking more time than expected. Correct problems of these types before you consider increasing the maxThreads setting for Apache Tomcat.

The following settings for Apache Tomcat have been shown to be able to sustain the most extreme loads. These settings might be higher than what is required in most cases (as outlined in the table). However, it might be desirable to set the values high and then trim them down through monitoring. For example, consider these configuration settings:

For Apache Tomcat heap size, the Apache Tomcat heap size minimum and maximum are recommended to be set to 12 GB in Siebel Application Interface and Siebel Gateway, with maxThreads set to 2000.
In setenv.bat, set the Apache Tomcat heap size to 12 GB on Siebel Application Interface and Siebel Gateway, using values like -Xms12288M -Xmx12288M.
In server.xml, set maxThreads to 2000.

When placing JAR files into Siebel WAR file as part of Integration Setup of Siebel with OCI AI Services, Unity or CrowdTwist, the Siebel Server and Gateway may not come up after Restarting Tomcat. This is caused due to a Java Runtime Environment (JRE) upgrade wherein there is a change in the Java System Property to control the Maximum Size of Signature Files. To resolve this issue, the value should be set to 16 MB instead of default value 8 MB.

Consider these Setenv.sh file settings:

JAVA_OPTS="$JAVA_OPTS -Xms512m -Xmx1024m -
Djdk.jar.maxSignatureFileSize=16000000"

To add Java System Property in Windows

Navigate to the bin folder of Tomcat's installed location.

Open the command prompt from the location.
Execute the command from the location C:\ <Tomcat installed Location>\bin> tomcat9w.exe //ES//<Tomcat Service Name>

Tomcat 9w: A GUI application for monitoring and configuring Tomcat services.
A graphical user interface (GUI) application is launched. Select the Java tab.
In the java -options add the below command and click OK button:
```
-Djdk.jar.maxSignatureFileSize=16000000
```
Navigate to the bin folder of Tomcat's installed location. Open the command prompt from the location.
Bounce the internal Tomcat.

To add Java System Property in Windows

Related Topics