Service Virtualization

Hello Team,

Think time scale is the time between request's reception and response or between request's processing and response ? 

In some cases, we may have different times for request's reception request's processing.

Consider one VS with capacity = 1 and think time scale = 10 seconds

I try to run this VS, I have to wait 10 seconds before answer.

Immediately, I try to run this VS again. Due to capacity = 1, this second run have to wait the end of the first .

I guess we have :

- instant of reception = when I try to run this VS the second time

- instant of processing = when my first run will be done (ie time of reception + 10 seconds)

And what about "think time scale" for the second answer ? It is from request's reception or request's processing ?

Best regards,

Benoit

Hi Benoit,

If I remember correctly, the think time that you are asking about is the time/delay from the moment the VS receives the request until it returns the response. If it takes your application 50ms to return the response to your application and another 50ms to process the response by your application, this additional 100ms is not counted towards your think time delay. It's as soon as the VS receives a payload until it sends off. This think time is specified at each of the transaction's level. 

On another note, think time scale is different than just think time. Think time scale is specified upon the deployment of a VS or creation of a MARI file. The think time scale will scale your think time according to the value specified. For example if you specified 50% for the think time scale then you are honoring 50% of the specified think time set at the transaction level. For example if one of your transactions is set to 500ms for think time then during runtime with a think time scale of 50% the virtual service will return the response in 250ms (e.g. 50% of 500ms). Likewise if you had set the think time scale to 200% then it will take twice as long to return the response. 

Hello William,

In other words, if I have a VS of capacity = 1 (therefore 1 thread) and think time = 10 seconds, for 2 consecutive calls, the first will answer in 10 seconds (think time) and the second in 20 seconds (think time of first call in order to have the only thread free, and the think time of second call), right ? 

Best regards,

Benoit

I don’t recall specifically testing this scenario, but “delayed” responses were at one time placed on a background thread so that processing could continue on the next request without waiting for the reply of the first to be sent. So, each request should receive a fairly accurate 10 second wait time (not 10 + 10).

Benoit,

If you are executing the requests/transactions consecutively (sequentially) then yes it will take 20 seconds to complete both transactions. However, I want to clarify that capacity value doesn't map 1-to-1 to number of thread instances. The virtual service is very likely to be able to service multiple concurrent requests even with the capacity set to 1. There's no actual formula set in stone to know the exact number of threads that are spun up in respect to the capacity value that is used. You would need to use some type of perfmon to monitor the number of threads that are created and it is dependent on the hardware resources on the server where the virtual service is deployed.

Hello,

I have tested and the wait time is about 10 seconds (and not 10 + 10).

And a bad new : after one request, the first response come with 10 seconds. After the first response, a new request and the response come too quickly (19 ms). During few seconds, responses are coming too quickly. And then a new response will take 10 seconds...

Any idea why ? 

Benoit

Wrong new, I think I have a cache problem on SoapUI. Using Firefox to request virtual service, the time to wait is always about 10 seconds.

Thanks for your help.

Benoit