The Save pane of the CA Service Virtualization Recorder displays the following options:
For each option, complete the following fields:
Determines the project where the virtual service is stored. Select a project from the drop-down list. Projects that are listed in the drop-down are projects that exist in the Projects directory,
Specifies whether to treat all recorded transactions as stateless. In most cases, leave this option cleared.
Default: Selected
Specifies whether to record duplicate specific transactions.
Default: Cleared
To display more options, click YES for Advanced Mode at the upper right corner of the window. Optionally, complete the following fields:
Specifies whether to generate a VSM including the prepare steps.
Values:
Default: More Efficient
Specifies the navigation tolerance that determines where in the conversation tree a VSM searches for a transaction that follows the specified transaction. Select the default navigation tolerance for all except the last (leaf) transactions.
Values:
Default: Wide
Specifies the navigation tolerance that determines where in the conversation tree a VSM searches for a transaction that follows the last (leaf) transactions.
Values:
Default: Loose
Save & Close saves the virtual service and closes the recorder tab.
Save & Deploy Virtual Service saves the virtual service and deploys it immediately.
Complete the following fields:
Specifies the name of the virtual service group for this virtual service. If deployed virtual services have group tags, they are available in the drop-down list. A group tag must start with an alphanumeric character and can contain alphanumeric characters and the following special characters:
Specifies a number that indicates the load capacity. Capacity is how many virtual users (instances) can simultaneously execute with the VSM. Capacity here indicates how many threads there are to service requests for this service model.
VSE allocates a number of threads equivalent to the total concurrent capacity. Each thread consumes some system resources, even when dormant. Therefore, for optimal overall system performance, set this setting as low as possible. Determine the correct settings empirically by adjusting them until you achieve the desired performance, or until increasing it further yields no performance improvement.
Out of the box protocols use a framework-level task execution service to minimize thread usage. For these protocols, a concurrent capacity of more than 2-3 per core is rarely useful, unless the VSM has been highly customized.
For extensions and any VSM that does not use an out of the box protocol, setting a long Think Time may consume a thread during the think time. In these cases, you can increase the concurrent capacity.
The following formula gives an approximate initial setting in these cases:
Concurrent Capacity = (Desired transactions per second / 1000) * Average Think Time in ms * (Think Scale / 100)
Example:
Assume that you are using a custom protocol that does not use the framework task execution service to handle think times. You want an overall throughput of 100 transactions per second. The average think time across the service image is 200 ms, and the virtual service is deployed with a 100 percent think scale.
(100 Transactions per second / 1000) * 200ms * (100 / 100) = 20
In this case, each thread blocks for an average of approximately 200 ms before responding, and during that time is unable to handle new requests. We therefore need a capacity of 20 to accommodate 100 transactions per second. A thread would become available, on average, every 10 ms, which would be sufficient to achieve 100 transactions per second.
Default: 1
Specifies the think time percentage for the recorded think time.
Note: A step subtracts its own processing time from the think time to have consistent pacing of test executions.
Default: 100
Examples:
Save & Edit Virtual Service saves the virtual service and opens it in edit mode in a new editor tab.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|