1. Performance Tuning Guide
  2. Sizing Considerations for Siebel CRM Version 17.0 and Later

Sizing Considerations for Siebel CRM Version 17.0 and Later

This topic provides information about sizing considerations applicable as of Siebel CRM version 17.0, relative to prior releases. The information in this topic supersedes or modifies similar information provided elsewhere in this guide.

Sizing for Siebel CRM Tier

Siebel CRM version 17.0 introduced new business agility and cloud support capabilities, including the following:

  • Siebel Application Interface, a new module, replaces Siebel Web Server Extension. Siebel Application Interface is a Java module conforming to the Java EE Web Profile standard and can run on any compliant application container (Web container). It is currently certified on and includes Apache Tomcat.

  • Siebel Gateway replaces the previous module by the same name. The Siebel Gateway registry, based on Apache ZooKeeper, replaces the siebns.dat file.

  • Siebel CRM server modules now use application containers on Apache Tomcat and Siebel REST API calls as part of the framework for configuration using Siebel Management Console (which replaces the Siebel Configuration Wizard) and for regular operations.

Both Siebel Application Interface and Siebel Gateway support distributed topologies, using Siebel Application Interface load balancing or Siebel Gateway clustering. For more information about these and related product changes, see Siebel Installation Guide and Siebel Deployment Planning Guide.

For Siebel CRM 17.0 and later releases, more memory and CPU are required compared to prior releases for Siebel Application Interface, Siebel Gateway, and Siebel Server. The following are observations made during the performance and scalability tests performed by Oracle:

  • Siebel Application Interface. The minimum memory (RAM) required for the Java Virtual Machine (JVM) heap size was observed to be 4 GB. The CPU usage is about 1% per 1,000 users and an additional 5% average CPU in case of a high login rate.

  • Siebel Gateway. The minimum memory required for the JVM heap size was observed to be 4 GB. The CPU usage is about 1% to 2% after the Siebel Servers have started (4% maximum CPU) and an additional 5% average CPU in case of a high login rate. The same recommendations apply for each node. Example for configuration:

    • It is recommended to set the JVM heap size minimum and maximum to 4 GB on Siebel Application Interface and Siebel Gateway.

    • On Microsoft Windows, you can set the JVM options using the tomcat8w utility. You must also specify the name of the service to which your setting applies. This utility is located in the SIEBEL_ROOT\applicationcontainer_internal\bin directory. Alternatively, you can set the heap size in setenv.bat to 4 GB (-Xms4096M -Xmx4096M). This batch file is located in the SIEBEL_ROOT\applicationcontainer_internal\bin directory.

    • On UNIX operating systems, set the heap size in setenv.sh to 4 GB (-Xms4096M -Xmx4096M). This shell script is located in the SIEBEL_ROOT/applicationcontainer_internal/bin directory.

  • Siebel Server. The memory requirement has increased by 20%. CPU usage has increased by 25%, on average, across all Siebel CRM applications.

For additional recommendations, see Tuning Apache Tomcat.

Several issues, fixes, and recommendations in these areas are reflected in corresponding alert articles available on My Oracle Support. For more information about configuring JVM options, see 2472920.1 (Article ID) on My Oracle Support. See also the Java documentation from Oracle. For information about stopping and starting the application container and related information, see Siebel Installation Guide and Siebel System Administration Guide.

The preceding information regarding CPU requirements assumes two sockets Hexacore Intel Xeon CPU X5670@2.93 GHz, and a total of 12 cores.

Note:

Customers moving to any release in Siebel CRM 23.x need to note that every Siebel release undergoes a rigorous evaluation process that includes performance, scalability, and reliability (PSR) testing. These tests have indicated that there's no substantial increase in system resource utilization when comparing Siebel CRM releases 19.x and before, and Siebel CRM version 23.x, except for higher utilization in the Siebel Application Interface (SAI) CPU and its associated Tomcat heap size.

Specifically, a CPU utilization increase ranging from 50% to 100% in the Siebel Application Interface (SAI) component was observed. In our dedicated PSR laboratory, the SAI typically consumes 5% to 10% of CPU resources on an Intel Xeon X5675 Hexa-Core Processor (3.06GHz, 2 x 6 cores), with the percentage varying based on the system load. Also, it is recommended to adjust the Tomcat heap size, which may range from 8GB to 12GB depending on the specific Siebel application under test.

However, it is important to note that the observed CPU increase may not significantly impact the overall system performance. This is primarily due to the consistently low SAI CPU usage, which generally hovers around 5%, and even less when the CPU increase is distributed across multiple SAIs in consideration of high-availability configurations.

Before the go-live phase, it is strongly recommended that you do a comprehensive performance testing on the Siebel application platform and later adjusting the aforementioned recommendations based on the test results.

Note: The sizing information in this topic is based on consolidation of several Siebel CRM performance and scalability tests. Actual results may vary, based on a broad range of implementation-specific factors, such as application configuration and customization, transaction mix, duration of each request, login storms, frequent incoming EAI requests requiring a new login, hardware or operating system platform, network parameters, database size, and so on. Oracle does not warrant or guarantee that customers will obtain the same or similar results. It is strongly recommended that you thoroughly test your Siebel CRM applications by performing performance and scalability testing with the expected volumes to determine your specific resource requirements. Oracle does not share the details of its internal tests. To address your requirements, it is strongly recommended that you engage Oracle Advanced Customer Support to do the sizing based on those needs.

Monitoring

The following information describes how to monitor the usage of JVM heap size and other important metrics, such as the number of concurrent threads or other performance factors. For the run-time heap usage and thread usage information, Oracle used the Java Mission Control utility and connected to the remote JVM. To enable JMX remote on UNIX operating systems, add the following arguments to the setenv.sh file for the Siebel Gateway and Siebel Application Interface installations. After enabling JMX remote, you can monitor heap usage, threads, and other metrics using the Java Mission Control dashboard (for example, you can add graphs).

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=7777
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder

For setting up JConsole please refer to the following link:

https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html

Overview, Memory, Threads and VM Summary tabs provide the most important indicators allowing to monitor the overall performance and to adjust the heap size if needed, etc.

Setting Up Garbage Collection Logs

The following table describes parameters that you can optionally specify to capture garbage collection logs for troubleshooting purposes.

Parameter Description Example/Comments

-verbose:cg

Enables logging of garbage collection (GC) information.

N/A

-XX:+PrintGCDetails

Provides details about GC logs, such as:

  • Size of the young and old generation before and after garbage collection

  • Size of total heap

  • Time it takes for garbage collection to occur in young and old generation

  • Size of objects promoted at every garbage collection

N/A

-XX:+PrintGCDateStamps

Records each verbose GC cycle with date and timestamp format.

N/A

-Xloggc:path/filename

Specifies the file to which to redirect GC information for logging.

-Xloggc:/vol1/siebel/applicationcontainer_internal/logs/gc.log

-XX:+UseGCLogFileRotation

-XX:NumberOfGCLogFiles=number_of_files

-XX:GCLogFileSize=file_size

Specifies file rotation for GC logs. Using file rotation makes log analysis easier and protects the disk from space overconsumption.

-XX:UseGCLogFileRotation

-XX:NumberOfGCLogFiles=10

-XX:GCLogFileSize=100M

Optional; recommended

-XX:PrintHeapAtGC

Prints the heap layout before and after garbage collection is logged.

Optional

-XX:+HeapDumpOnOutOfMemoryError

Generates a heap dump when an allocation from the Java heap or the permanent generation cannot be satisfied. There is no overhead in running with this option, which is useful for production environments where the OutOfMemoryError exception takes a long time to surface.

Optional

-XX:HeapDumpPath=path

Specifies where to generate the heap dump.

-XX:HeapDumpPath=/vol1/siebel/applicationcontainer_internal/heapdumps

Optional

Related Topics

Tuning Apache Tomcat