Behavior Settings
On the Behavior page of the virtual service editor, you can configure various aspects of the service functioning, like network bandwidth, error simulation, and others.
Important
To use these settings, you need a ReadyAPI Virtualization license.
The Hardware, Network , and Errors settings described below apply only to REST and SOAP services. JMS virtual services use other settings.
Hardware
Use the Hardware settings to emulate the machine's performance where your virtual service will run. You can choose predefined values by selecting one of the Server Capacity options, or choose completely custom values:
Setting | Description |
|---|---|
Min Threads and Max Threads | The minimum and maximum number of requests that the virtual service can handle simultaneously. |
Response Delay | The number of milliseconds that pass after the service forms the response data and before it sends this response. |
The Server Capacity options let you quickly specify the machine performance, from S (lower performance) to XL (powerful server). When you select an option, you can see the appropriate values in the , , and edit boxes.
Note
The computer on which you will run the virtual service must be powerful enough to deliver the performance you choose.
Network
Use the Network settings to customize network bandwidth. This section includes the following settings:
Setting | Description |
|---|---|
Connection Bandwidth | The network connection capacity to simulate. |
Latency | The network package delay to be simulated. This time will be added to the time during which the service waits before sending a response to a client. Default: 0 milliseconds. |
Congestion | The network's utilized capacity to be emulated. Lower values mean the network is “free”. Higher values simulate a “busy” network. A value of 100% means the network is busy, but it can still handle individual rare requests. The effect of this setting is noticeable only if you send a large number of requests to your virtual service. The higher this setting value is, the longer the response time you will get. If the is low and is high, the service may refuse to process some requests (you will get timeout errors on the client side). Default: 0%. |
Errors
Use the settings of the Errors section to simulate errors in the work of your virtual service. For example, with these settings, you can simulate a situation in which your service returns an error for any request after a period of successful operation. You can also specify the duration of the “malfunctioning”, after which the virtual service will return to “normal” processing. This will let you check how the client software handles a temporary period of service unavailability.
Using these settings, you can simulate error responses for the entire service. It will use these settings to reply to any request. If you need to simulate error responses only for some requests, configure the dispatch settings.
The Errors section includes the following settings:
Setting | Description |
|---|---|
Error Code | HTTP response code of the simulated error. The virtual service will return this error for all the requests. |
Start sending errors after | The time, in seconds, after the service start at which the service begins returning an error. Default: 0 seconds, which means the service will begin replying with an error to the very first request. |
Duration | Specifies the time period during which the virtual service will simulate the error:
|
Error Body | Specifies the body contents of the error response. |
JMS Behavior
JMS virtual services use only three behavior settings. If you need more complex behavior, you will have to use scripting or use your JMS provider features.
Setting | Description |
|---|---|
Latency | The network package delay to be simulated. This time will be added to the time during which the virtual service waits before sending a response to a client. Default: 0 milliseconds. |
Response Delay | The number of milliseconds that pass after the service forms the response data and before it sends this response. |
Max Threads | The maximum number of requests that the virtual service can handle simultaneously. |