Chapter 9 Using the Performance Monitor

Configuring response rate thresholds

Response rate thresholds specify the maximum allowable average response time before the server blocks requests for new component instances or network connections. You can configure response rate thresholds for individual business components and each network protocol.

Component settings

For components, you can configure response rate thresholds on the Resources tab in the EAServer Manager Component Properties dialog box. Set the fields listed in Table 9-2.

Table 9-2: Component response rate threshold settings
Field	Description
Maximum Response Time	The maximum allowable average response time for the component, in seconds. If the average method completion time rises above this limit, EAServer blocks creation of additional instances of this component until the average drops below the specified limit. The default is -1, which indicates no time limit. If using jagtool or an external configuration file, you can configure this setting as com.sybase.jaguar.component.monitor.MaxRespTime.
Minimum Number of Instances	When the Maximum Response Time is set to a non-default value, specifies the minimum number of instances that must be allowed to execute regardless of observed response times. The default is -1, which means no new instances are blocked by the Performance Monitor. If using jagtool or an external configuration file, you can configure this setting as com.sybase.jaguar.component.monitor.MinInstance.

Listener settings

To configure thresholds for network throughput, configure the listener properties for the client protocol that requires the threshold. Set the fields listed in Table 9-3 on the Resources tab in the EAServer Manager Listener Properties dialog box.

Table 9-3: Listener response rate threshold settings
Field	Description
Maximum Response Time	The maximum allowable average response time for each request, in seconds. If the average response time rises above this limit, EAServer blocks additional connections until the average drops below the specified limit. The default is -1, which indicates no time limit. If using jagtool or an external configuration file, you can configure this setting as com.sybase.jaguar.listener.monitor.MaxRespTime.
Minimum Number of Connections	When the Maximum Response Time is set to a non-default value, specifies the minimum number of clients that must be allowed to execute regardless of observed response times. The default is -1, which means no new connections are blocked by the Performance Monitor. If using jagtool or an external configuration file, you can configure this setting as com.sybase.jaguar.listener.monitor.MinInstance.

Tuning response rate thresholds

Tune the response rate threshold settings when your performance testing indicates a severe degradation of server performance under load. When tuning, consider the following:

Deciding where to apply the settings

You can apply response time thresholds to components or listeners. Choose the entity that has the greatest affect on client load and that has the least unintended effects on other applications running in the same server. For example:
- If the application front end is a Web application, apply the settings to your HTTP listener since all client requests pass through it.
- If clients connect to EJB session beans, apply the settings to the session bean components, so that the number of session bean instances governs the applied load.
- If a component accesses a database, and the client load tends to overwhelm the database, apply a response-time threshold to this component to throttle the database load to manageable levels. (You could also tune the connection cache size as described in "Connection cache settings".)
WARNING!
When applying response rate thresholds to components, some configurations can introduce the possibility of deadlock—see "Avoiding deadlock scenarios".
Choosing a response time threshold

Use performance testing under controlled client loads to determine a realistic value for response times under high load conditions. Apply this setting as the allowable Maximum Response Time for the component or listener. This setting prevents response times from growing exponentially under worst-case load conditions; it does not make the server run faster.
Specifying a minimum number of instances or network connections

Decide how many clients your application should serve, even under worst- case load conditions. Configure this value as the minimum number of instances or network connections.

Avoiding deadlock scenarios

When you apply response time thresholds to components and specify a low number of minimum instances, the server may deadlock with some application architectures, including:

Components that make intercomponent calls and that are invoked directly by base clients.
Components that call themselves recursively and are also invoked by base clients.

To understand how deadlock can occur and how to avoid it, you must first understand how the Performance Monitor governs client load. During normal operation (after server start-up), Performance Monitor governs load as follows:

Before an entity starts executing a request, it calls the Performance Monitor to check whether it should proceed.
The Performance Monitor checks the entity's threshold properties and measured average response time. Based on these values, the entity is blocked temporarily or allowed to execute.
After the request completes, the entity again calls the Performance Monitor, allowing measurement of the actual execution time. Performance Monitor adds this to the average time for the entity.

If the average time is lower than the configured threshold, Performance Monitor increases the maximum allowable simultaneous instances for the entity by one. On the other hand, if average time is higher than allowed, it reduces maximum allowable instances by one.

This reduction in maximum allowable instances will continue until maximum allowable Instances is equal to configured Minimum Number of Instances.

During server start-up, Performance monitor uses the same algorithm, but starts with the configured value for Minimum Number of Instances as the maximum number of instances that can execute. The number of instances can grow if initial response times are lower than the specified threshold.

When components make intercomponent calls and are invoked directly by base clients, deadlock can occur when client invocations have exhausted the allowable number of instances, and intercomponent calls require the creation of additional instances. Consider components A and B, both with response-time thresholds configured and a value of 5 for Minimum Allowable Instances, and the following sequence of events:

Five clients invoke A and B, creating five instances of each component.
A attempts to call B, but is blocked because measured response times are over the threshold (or the server is just starting, and no response times have been measured).
B attempts to call A, but is blocked because measured response times are over the threshold. A and B are deadlocked.

To avoid this pitfall, you can either remove response time monitoring from the components and apply it to the network listener, or split the component logic into two sets of components. Create a thin wrapper to be invoked by base clients, calling the original component to invoke the logic that requires intercomponent calls. Configure response time monitoring only on the wrapper components that are invoked directly by the base clients.

A component that calls itself recursively can deadlock in a similar scenario. The cure is also similar. Remove response time monitoring from the components and apply it to the network listener, or create a wrapper component to be invoked by base clients and call the recursive component, with response time monitoring configured for the wrapper component instead of the recursive component.

If you suspect your components may be deadlocked due to response time monitoring, analyze the stack traces in the performance monitor statistics.