Performance

Notification Server

This section describes how to configure performance settings for the SBM Mail Services. For distributed installations, you configure these settings directly on the server or servers where the SBM Mail Services are installed.

• Process Rate Control Settings

  The Notification Server's process rate setting controls the frequency with which the Notification Server cycles through new change records that are generated by end users, creates events based off those changes, and sends messages according your notification rules. This setting impacts the load bearing capabilities of the Notification Server.

  To configure process rate settings for the Notification Server, use the slider to change the process rate level to one of the following options:

  • Level 1 – Very low load level. At this level, the average cycle rate is two minutes. Use this setting if your users generate very few changes.
  • Level 2 – Low load level. At this level, the average cycle rate is one to two minutes. Use this setting if your users generate occasional changes.
  • Level 3 – Average load level. At this level, the average cycle rate is one minute. Use this setting if your users generate consistent changes.
  • Level 4 – High load level. At this level, the average cycle rate is thirty second. Use this setting if your users make several changes often.
  • Level 5 – Maximum load level. At this level, the average cycle rate is five to ten seconds. Use this setting if several of your users make numerous changes daily.
• Cache Expiration Time Control Settings

  The Notification Server uses the ehCache framework to store data in the local cache from several tables in the SBM Application Engine database. The reliance of this cache has a direct impact on the system's performance, so consider monitoring and adjusting the cache limit as necessary.

  • If you find that SBM performance on this machine is suffering, consider increasing the Notification Server's cache level, which decreases the number of database reads made by the Notification Server.
  • If you find that the performance of the Notification Server itself is lagging, you could decrease the cache level, thereby decreasing the Notification Server's dependency on system memory and forcing more direct database reads, which will improve Notification Server processing times but may affect other server components.
  • To configure cache expiration time limit options for the Notification Server, use the slider to change the cache level.
    • Level 1 – Low cache capability. This setting forces the Notification Server to consume much less memory, but increases usage of the database for table reads.
    • Level 2 – Average cache capability. At this level, the Notification Server attempts to evenly balance both system memory consumption and database usage for table reads.
    • Level 3 – High cache capability. This setting forces the Notification Server to consume a greater amount of memory, but decreases usage of the database for table reads.
• Attempt to send all Notifications for an item

  Select this option to have the Notification Server attempt to send every applicable notification for an item, regardless if the notifications might no longer be applicable.

  • Normally the Notification Server does not send e-mail messages each time an item changes state if the changes happen in rapid succession. Instead, the service assumes that an e-mail should be sent for only the last state change that occurs.
  • If you enable this setting, the Notification Server attempts to send messages for each individual change that occurred, even if the change is no longer relevant to the current status of the item.
  • Once this option is selected, the following slider control is not applicable.
• After initial send, skip changes accumulated in the next

  Use this slider to set the time period for which changes should be skipped by the Notification Server for a particular item after the first notification is sent.

  • The default value is sixty seconds.
  • This means that after processing an initial change and sending a notification, the rest of the changes that occur against the item for the next sixty seconds are skipped before a new change is processed and another notification is sent.
  • This setting is useful if you do not want to receive all of the notification messages that are generated when an item is moved from state to state in rapid succession. These messages might become redundant if the item is transitioned several times, and you might not want to receive all the notification messages that were generated while the item was still in flux.

Web Services

SBM Application Engine and SBM Orchestration Engine can potentially invoke several Web service calls depending on your usage and configuration model. To manage these calls, adjust performance settings in SBM Configurator to "throttle" the Web service activities for each component. When a threshold has been reached, subsequent calls are rejected. The Common Log is updated with these failures.

The SBM Application Engine calls referred to in this topic refer to calls made directly into the SBM Application Engine Web services provided by SBM. Calls made to third-party Web services are not affected by the settings in this file.

Throttling is disabled for both components by default. Consider enabling throttling to safeguard against denial of service attacks or inadvertent high-volume repeat Web service invocations. To enable throttling for SBM Application Engine Web service calls, select the Enable throttling of Application Engine Web services check box. Similarly, select the Enable throttling of Orchestrations to impose limits for the SBM Orchestration Engine.

In the Whitelisted users table, set specific throttling parameters for a particular user or users that can override the default settings defined above. You may find this useful if you often designate a single user to perform all your Web service calls (perhaps from within an orchestration). For example, you can "whitelist" a certain user account that is used only for authentication purposes in Web service calls, which thereby requires a higher threshold.

To "whitelist" specific user accounts:

1. Click Add.
2. Enter the user login ID.
3. Enter the maximum number of allowed Web service invocations.
4. Enter the number of seconds.
5. Enter the maximum payload size.

Orchestrations

In the SBM Orchestration Engine section, you throttle the activity and load handling forSBM Orchestration Engine. You use the throttling controls to tune the SBM Orchestration Engine server behavior to your applications. By default, SBM allows fifteen simultaneous orchestration executions (either synchronous or asynchronous) whether you enable or disable throttling for orchestrations. Adjusting the throttling numbers enables you to control the trade off between delays in orchestration processing and server resource usage in order to avoid out-of-memory conditions from occurring while the server is under load. The values that you set depend on the computing resources available to the SBM Orchestration Engine server and how your orchestration workflows use those resources.

To properly adjust the throttling controls for your environment, consider the following:

• Reducing the number lowers the risk of an out-of-memory condition, but it might delay orchestration workflows from finishing because they have to wait to execute. For synchronous orchestrations, this delay might cause timeouts that are undesirable for users.
• Increasing the number raises the risk of an out-of-memory condition, but it enables more requests to be processed immediately.
• The optimal setting balances the two extremes for a particular process app. If your orchestration workflows perform a lot of calculation, then allowing less concurrency might prove optimal. If the orchestration workflows mostly call Web services, then allowing more concurrency might help.

Determining the optimal settings is likely a matter of trial and error; however, changing the default value is not generally necessary unless you are experiencing out-of-memory conditions or delays in orchestration execution. If both conditions exist, then consider increasing the amount of memory or CPU, or create a cluster for the SBM Orchestration Engine.

Event Manager Log Entries

Select the Remove all successful Event Logs upon completion check box to have the system automatically remove Event Log records for events that are processed successfully on the first attempt. Note that this option is disabled if the database has not been initialized, or no event data has been processed. You can select this option once the system has processed an asynchronous orchestration.