Performance

These settings control how often the Notification Server cycles through new change records that are generated by 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:

• Minimum load level – At this level, the average cycle rate is two minutes. Use this setting if your users generate very few changes.
• Low load level – At this level, the average cycle rate is one to two minutes. Use this setting if your users generate occasional changes.
• Average load level – At this level, the average cycle rate is one minute. Use this setting if your users generate consistent changes.
• High load level – At this level, the average cycle rate is thirty second. Use this setting if your users make several changes often.
• Max 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.

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.
  • Low cache capability – This setting forces the Notification Server to consume much less memory, but increases usage of the database for table reads.
  • Average cache capability – At this level, the Notification Server attempts to evenly balance both system memory consumption and database usage for table reads.
  • Max cache capability – This setting forces the Notification Server to consume a greater amount of memory, but decreases usage of the database for table reads.

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.

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.

Designate the amount of time SBM should wait for calls made to Application Engine Web services. This setting applies to Web service functions assigned to transitions, states, and notifications. The default setting is 30 seconds.

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, you can adjust performance settings in SBM Configurator to "throttle" the Web service activities for each component. You can also throttle Web services to safeguard against denial of service attacks or inadvertent high-volume repeat Web service invocations. When a threshold has been reached, subsequent calls are rejected. The Common Log is updated with these failures.

• Maximum number of invocations

  Enter the maximum number of allowed Application Engine Web service invocations per second.

• Maximum payload size

  Enter the maximum threshold size for the payload (amount of data) that is sent with a Web service call (for calls into Application Engine Web services).

• Send throttle notifications to

  Select this check box and enter an e-mail account to receive notifications when a limit has been reached. The e-mail account does not need to be associated with an SBM user.

• Whitelisted users

  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 specify a certain user account that is used only for authentication purposes in Web service calls, which thereby requires a higher threshold.

Designate the amount of time SBM Orchestration Engine should wait for an external Web service response for a call initiated from an orchestration. The default setting is 120 seconds.

This is the maximum time for BPEL process execution (for synchronous and asynchronous orchestrations). This prevents infinite loops from occurring, which can cause orchestrations to never finish.

The default is 600 seconds (10 minute). If the timeout is reached, the orchestration will fail on the next step (such as a calculate step or service call). You can increase the timeout in case you have asynchronous orchestrations that require more than 10 minutes to complete.

If the Application Engine Web services invocation timeout is reached before a response from the synchronous Orchestration Engine call, a fault response from Application Engine is generated ; however, the orchestration will continue to execute up until the Orchestration execution timeout value.

Enter the maximum payload size for Web service responses that can be received by the SBM Orchestration Engine.

Enter the maximum number of orchestrations that can be executed at the same time. Orchestrations are processed according to when they are received and the priority that is assigned to the event definition in SBM Composer.

By default, SBM allows 40 simultaneous orchestration executions (either synchronous or asynchronous). You can adjust this value 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 Orchestration Engine server and how your orchestration workflows use those resources.

Note 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.

Select this 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.