Performance tab

With the Performance tab, you can change the performance characteristics of the stub by adding delays during stub execution.
Note:

The delay is the minimum time from the start of message event processing to when the stub sends any message. The message can be a Publish action or a Send Request action (to start another service). The Business Logic of the stub starts execution immediately, but the first message action cannot be run until the delay is reached. In cases where the Business Logic takes longer than the delay time, no further delay is added before the message is sent.

The response time can be overridden when you deploy the stub with HCL Quality Server.

The image shows a table of operations with associated delay types and configuration information.
For each operation in the Response Times section, provide a delay Type and Configuration information. The following delay types are available:
No delay
The default.
Minimum
Delays can exceed this value, but not fall below it. Specify the following configuration information:
Minimum response time
The number of milliseconds of delay to be added by HCL OneTest™ API.
Gaussian
Delays vary between a minimum and maximum, with a "bell curve" type of distribution. Specify the following configuration information:
Minimum response time
The low end of the Gaussian distribution.
Maximum response time
The high end of the Gaussian distribution.
Uniform
Delays vary between a minimum and maximum, with an even distribution of values. Specify the following configuration information:
Minimum response time
The low end of the uniform distribution.
Maximum response time
The high end of the uniform distribution.
Performance Profile
Delays are based on a performance profile. For information about creating and using a performance profile, see Creating performance profiles.
The following Tuning fields apply to all operations:
Workers
The maximum number of concurrent instances of this stub that can run at the same time. The default is 10.
Disable performance optimizations
If you clear this check box, HCL OneTest API attempts to reduce the amount of processing between the time a stub receives a request and the time it sends a response. Specific optimizations depend on the message contents, as in the following examples:
  • When the stub receives requests, all validations are disabled, and for all XML payloads, store and filter actions are converted to use XPath expressions.
  • When the stub sends responses, any store actions set on a message are disabled, and any XML content is collapsed when the stub is compiled instead of being collapsed every time that a response is sent.

Performance optimization is disabled by default and should be used with caution.

If you configured the stub to not delay the message at all, but the stub still runs too slowly, possibly due to the time it takes to run the actions for the stub, consider the following options:
  • Turn off logging
  • Minimize the number of actions in the stub
  • Increase the number of Workers (instances of the stub) to match the number of native threads that are available on the machine where the stub is deployed
Note: In HCL OneTest API, stubs are throttled to 1 transaction per second (TPS), whereas stubs in HCL OneTest Virtualization run at full speed.
Feedback