Performance tuning

 This topic provides recommendations for tuning the deployment of BMC Release Process Management for optimal performance.

Recommended configurations

Depending on the RPM version you are using, see one of the following:

Recommended configurations for 5.0.03.004 and later versions

Use the following configurations for optimal performance of the product:

  1. Navigate to the RLMhome/releases/yourCurrentVersion/RPM/portal.war/WEB-INF/config directory and open the wildfly.yml file with a text editor.
  2. In messaging, perform the following steps to set the number of job to be executed:
    1. For the concurrency parameter in the AutomationHandler, enter the number of processors. The default is 6.
      For example, if you want to set 10 processors for the automation queue, your concurrency parameter is the following:
      messaging:
           /queue/backgrounds/automation:
                AutomationHandler:
                    concurrency: 10

    2. Under ScheduledJobHandler, set the concurrency parameter to the number of scheduled jobs that must be processed without delay. The default value is 5:
      For example, if you want to set 3 processors for the queue, you concurrency parameters is the following:
      messaging:
           /queue/backgrounds/automation
                ScheduledJobHandler:
                     concurrency: 3

      Note

      The number of parallel automation jobs which are executed at a time depends on the number of available logical processors. This number is calculated using the following formula:

      Maximum parallel consumers  =  Number of logical processors * 8.

      We recommend that you specify the concurrency parameter based on the available logical processors.

  3. Go to the RLMhome\releases\productVersion\RPM\portal.war\WEB-INF\config directory and open the database.yml file with a text editor.

  4. Ensure that the following parameters are set in the file:

    production: 
      ...

      pool: 10 # NOTE: Increase the connection pool size
      wait_timeout: 10
      cursor_sharing: EXACT

    Note

    By default, the cursor_sharing value is set as FORCE. This overrides any configuration set on the database at the system level. Specify the value for cursor_sharing as EXACT to avoid performance issues.

  5. Go to the RLMhome\releases\productVersion\RPM\portal.war\WEB-INF\config directory and and open the automation_settings.rb file with a text editor.

  6. Ensure that the following automation parameters are set in the file:

    ...
    $AUTOMATION_JAVA_OPTS = "-Xmx512m -Xms256m -Xss2048k"
    ...

    If the automation_settings.rb file is absent, ensure that the provided automation parameters are set in the automation_settings.default.rb file at the same location.

  7. Ensure that the following application parameters are set in the start file:

    • (Windows, start.bat) 

      ...
      set JAVA_OPTS="%JAVA_OPTS% -Xms1024m -Xmx4096m -XX:+CMSClassUnloadingEnabled"
      ...

    • (Linux, start.sh)

      ...
      export JAVA_OPTS="$JAVA_OPTS -Xms1024m -Xmx4096m -XX:+CMSClassUnloadingEnabled"
      ...

    • (Solaris, RLMhome\bin\start.sh)

      ...
      JAVA_OPTS="$JAVA_OPTS -Xms1024m -Xmx4096m -XX:+CMSClassUnloadingEnabled"
      ...

Notes

  • In application and automation parameters, specify the Java memory settings for heap size in megabytes (m). For example: -Xms1024m -Xmx4096m.
  • In automation parameters, specify the stack size in kilobytes. For example: -Xss2048k.
  • After changing the configuration, restart the application service.


Recommended configurations for 5.0.03.003 and earlier versions

Use the following configurations for optimal performance of the product:

  1.  Navigate to the RLMhome/releases/yourCurrentVersion/RPM/config directory and open the torquebox.yml file with a text editor.

  2. In messaging, for the concurrency parameter, enter the number of processors for the automation queue. Default is 3.
    For example, if you want to set 8 processors for the automation queue, your concurrency parameter is the following:

    messaging:
      /queues/backgroundable/automation:
        AutomationHandler:
          concurrency: 8

  3. Navigate to the RLMhome\releases\productVersion\RPM\config directory and open the database.yml file with a text editor.

  4. Ensure that the following parameters are set in the file:

    production: 
      ...

      pool: 10 # NOTE: Increase the connection pool size
      wait_timeout: 10
      cursor_sharing: EXACT

    Note

    By default, the cursor_sharing value is set as FORCE. This overrides any configuration set on the database at the system level. Specify the value for cursor_sharing as EXACT to avoid performance issues.

  5. Navigate to theRLMhome\releases\productVersion\RPM\config directory and open the automation_settings.rb file with a text editor.

  6. Ensure that the following automation parameters are set in the file:

    ...
    $AUTOMATION_JAVA_OPTS = "-Xmx512m -Xms256m -Xss2048k"
    ...

    If the automation_settings.rb file is absent, ensure that the provided automation parameters are set in the automation_settings.default.rb file at the same location.

  7. Ensure that the following application parameters are set in the start file:

    • (Windows, start.bat) 

      ...
      set JAVA_OPTS="%JAVA_OPTS% -Xms1024m -Xmx4096m -XX:+CMSClassUnloadingEnabled"
      ...

    • (Linux, start.sh)

      ...
      export JAVA_OPTS="$JAVA_OPTS -Xms1024m -Xmx4096m -XX:+CMSClassUnloadingEnabled"
      ...

    • (Solaris, RLMhome\bin\start.sh)

      ...
      JAVA_OPTS="$JAVA_OPTS -Xms1024m -Xmx4096m -XX:+CMSClassUnloadingEnabled"
      ...

Notes

  • In application and automation parameters, specify the Java memory settings for heap size in megabytes (m). For example: -Xms1024m -Xmx4096m.
  • In automation parameters, specify the stack size in kilobytes. For example: -Xss2048k.
  • After changing the configuration, restart the application service.

Verified parameter combinations

The following table provides a combination of verified parameters and hardware recommendations that you can use for optimal performance of the product. The sets included in the table are presented in an increasing order of performance and faster response time.

Parameter combinations

Parameter

Set 1 values

Set 2
Values

Comments

Concurrent users

< 10

30

These are simultaneous users hitting web GUI simultaneous + users triggering requests with automations.

MaxPermSize

512 MB

512 MB

None

ms

1024 MB

1024 MB

Minimum Java heap size. To improve the application performance, BMC recommends setting the same maximum Java heap size value for both minimum and maximum Java heap size parameters.

mx

2048 MB

4096 MB

Maximum Java heap size. To improve the application performance, BMC recommends setting the same maximum Java heap size value for both minimum and maximum Java heap size parameters.

concurrency

3

3

The count presented in the sets indicate the number of parallel-automated steps that can run concurrently.

pool

10

30+

Pool indicates the maximum number of database connections made by the application. This count must be less or equal to the maximum connections configured in a database server.

Recommended hardware

Set 1 values

Set 2 values

 

CPU cores

2

4

None

Physical memory

4 GB

8 GB

Tip: You can calculate the optimal physical memory size for your environment using this formula.

Back to top

Calculating physical memory size

The recommended physical memory size required to run RPM depends on the JAVA_OPTS parameters that define the memory used by the servers and automation. The maximum JAVA_OPTS value that is defined by default for servers is 4096 MB and for automation is 128 MB. You can increase these parameters and calculate the required physical memory size based on your changes. For more information on how to modify the JAVA_OPTS values, see .

To calculate the minimal physical memory size

Memory = 1.5 × Xmx(JAVA_OPTS) + concurrency × Xmx(AUTOMATION_JAVA_OPTS)

  • Xmx(JAVA_OPTS)—The maximum size of the memory allocation pool for servers defined in the RLMhome\bin\start.bat (Windows) or RLMhome\bin\start.sh (Linux or Solaris) file
  • concurrency—A number of automation handlers defined in the wildfly.yml Version 5.0.03.004 or later or torquebox.yml Version 5.0.03.003 or earlier file
  • Xmx(AUTOMATION_JAVA_OPTS)—The maximum size of the memory allocation pool for automation defined in the automation_settings.rb file
Example

  1. If you have the following parameters set in your Linux environment:

    • {{code language="none"}}
      JAVA_OPTS="
      {{/code}}      $JAVA_OPTS -Xms1024m -Xmx4096m -XX:+CMSClassUnloadingEnabled"
    • concurrency: 3
    • $AUTOMATION_JAVA_OPTS = "Xmx128m -Xms32m -Xss2048k"
    Memory = 1.5 × 4096 + 3 × 128 = 6528 MB ≈ 7 GB

  2. If you have the following parameters set in your Linux environment:

    • JAVA_OPTS="$JAVA_OPTS -Xms1024m -Xmx8192m -XX:+CMSClassUnloadingEnabled"
    • concurrency: 0
    • $AUTOMATION_JAVA_OPTS = "-Xmx128m -Xms32m -Xss2048k"
    Memory = 1.5 × 8192 + 0 × 128 = 12288 MB ≈ 13 GB


To calculate the recommended physical memory size

Memory = 2 × Xmx(JAVA_OPTS) + concurrency × Xmx(AUTOMATION_JAVA_OPTS)

Example

If you have the following parameters set in your Linux environment:

  • JAVA_OPTS="$JAVA_OPTS -Xms6144m -Xmx6144m -XX:+CMSClassUnloadingEnabled"
  • concurrency: 10
  • $AUTOMATION_JAVA_OPTS = "-Xmx512m -Xms32m -Xss2048k"
Memory = 2 × 6144 + 10 × 512 = 17408 MB ≈ 18 GB

Back to top

Recommended deployment

The following table provides information about a recommended deployment scenario.

Note

This deployment can sustain a load of 60 concurrent users in case of a High Availability (HA) environment and 30 concurrent users in case of a Non-High Availability (Non HA) environment.

Deployment scenario

Scenarios

Percentage of total concurrent users

Transaction rate 
(per user, per hour)

Users creating and executing 100% automated requests

10%

4

Users maintaining plans and handling associated requests

10%

4

Users interacting with started requests

50%

2

Users creating requests, steps, and procedures

20%

4

Users using other tabs such as the Reports tab

10%

4

Performance tuning for a high-availability cluster environment

BMC recommends the following settings for an optimal performance in a cluster environment. 

For versions 5.0.03.004 and later versions, see:

For versions 5.0.03.003 and earlier versions, see:

To modify configuration setting for JBoss in the sysctl.conf file

  1. On the server where BRPM is installed, go to command prompt and run the cd /etc command to access the /etc folder. 
  2. Run the # cat sysctl.conf command to view the sysctl.conf file.

  3. Specify the recommended values for the following UDP parameters in the sysctl.conf file.

    # Allow a 25MB UDP receive buffer for JGroups
    net.core.rmem_max = 26214400
    # Allow a 1MB UDP send buffer for JGroups
    net.core.wmem_max = 1048576

    The following figure shows the updated values for the UDP parameters.
    jboss sysctl.png

  4. To apply this setting, run the sysctl -p command.

To update JVM tuning settings

  1. Go to RLMhome/bin and open the start.sh file.

  2. Add the following JVM tuning settings to the file:

    JAVA_OPTS="$JAVA_OPTS -Xms8g -Xmx16g -XX:MetaspaceSize=512m

    The following figure shows the updated JVM settings.

    jvm settings.png

  3. Save changes and restart the application service.

5.0.03.003 or earlier To modify configuration settings for HornetQ

  1. Go to RLMhome/releases/RLM/server/jboss/standalone/configuration and open the standalone-ha.xml file.
  2. In the file, ensure that the following parameters are set with the recommended settings. 

    1. Specify the <journal-file-size> as 10 MB. 

      Example
      <journal-file-size>10485760</journal-file-size>

    2. Specify <journal-min-files> as 6.

      Example
      <journal-min-files>6</journal-min-files>

    3. Specify <redelivery-delay> as 10 seconds.

      Example
      <redelivery-delay>100000</redelivery-delay>
  3. Save changes to the file.

5.0.03.003 or earlier To add configuration settings for JBoss in the standalone file

  1. Go to RLMhome/server/jboss/standalone/configuration and open the standalone-ha.xml file. 

  2. In the file, in the <protocol type="MERGE3"> protocol type, specify the following properties:

    <property name="min_interval">20000</property>
    <property name="max_interval">100000</property>

  3. In the <protocol socket-binding="jgroups-udp-fd" type="FD_SOCK"/> parameter, specify the following properties:

    <protocol type="FD">
    <property name="timeout">6000</property>
    <property name="max_tries">5</property>
    </protocol>
    <protocol type="VERIFY_SUSPECT">
    <property name="timeout">2000</property>

  4. In the <protocol socket-binding="jgroups-mping" type="MPING"/> parameter, specify the following properties:

    <protocol type="MERGE3">
    <property name="min_interval">20000</property>
    <property name="max_interval">100000</property>

  5. In the <protocol socket-binding="jgroups-tcp-fd" type="FD_SOCK"/> parameter, specify the following properties: 

    <protocol type="FD">
    <property name="timeout">6000</property>
    <property name="max_tries">5</property>
    </protocol>
    <protocol type="VERIFY_SUSPECT">
    <property name="timeout">2000</property>
  6. Save changes. 

Back to top

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*