Service Virtualization

Hi All,

Please find below my use case and support in providing the optimal solution for the same.

I am currently having a IBM MQ based VSM  which serves following scenario.

1) Once the request is reached to listen step, I need to send back the ACK response on a ACK Queue. (Response selected from VSI, where i have kept a think time) 

Question - I need to vary this think time between a range i.e 0 to 500ms. How do i do this?

2) After the ACK response is sent, I have another publisher step in which I am posting a message on 2 another Queues one after the other.

a) Reffered message on the Queue

b) Approved message on the Queue.

Requirement :- Requirement of the testing team is that the referred message should be posted on the Queue with variable think time.

30% of the times it should have delay as between 501ms-18s

30% of the times it should have delay as between 19s-38s

40% of the times it should have delay as between 39s-59s

Question :- 

a) in the VSM, how do i set the think time while using IBM MQ publish step(depreciated). I believe using a java script step before this step and using Thread.sleep is not a best approach. How shall i introduce the delay.

b) How do i fluctuate the delay based on the load criteria mentioned above.

Josh_Hendrick any thoughts?

Hi Vinit,

For the first part:

Think time spec

Enter the amount of think time that is required, in milliseconds. The think time is the time that is taken before sending out the response to a request. The default setting is 0. If you enter a range, the think time is randomly selected within that range. For example, 100-1000 specifies a random think time from 100 through 1000 milliseconds. You can specify time measurements by adding a suffix to the numbers (case does not matter). For example, 10t-5s indicates a random think time between 10 milliseconds and 5 seconds. The valid suffixes include:

• • t---milliseconds
  • s---seconds
  • m---minutes
  • h---hours

For the second part of your question around variable think times based on percentages, you may want to add a scripting step into your VSM to calculate the appropriate think time spec format and store that within a property in testExec.  Then in the think time spec section of your service image you should be able to reference the property using {{ }} notation.

Josh

Hi Josh,

For the second part - I am not using any VSI, I am just sending an XML in the Response Queue by using the IBM publisher step so that logic of sending the think time spec will not hold of here. How can I mention the think time when using the IBM MQ step.

Moreover, about the logic for the incoming requests hitting the vsm, in which i need to set dynamic response times. Any suggestion?

30% of the times it should have delay as between 501ms-18s

30% of the times it should have delay as between 19s-38s

40% of the times it should have delay as between 39s-59s

Josh_Hendrick any thoughts

With a regular, non-VSI step the think time is on the step itself.  Just like with a VSI response's think time, you can use a {{...}} expression in a step's think time and script it however you like.

However, this is not a good way to do think time with VSE if you want to have any kind of throughput.  This is equivalent to using Thread.sleep(); it will block that VS thread until the think time is elapsed.  With an average think time of about 30 seconds, you would need to set the capacity of your VS very high in order to handle any kind of load.

I don't know all the details of your scenario, but you can probably do all of this through your VSI without adding extra steps to the VSM.  Your VSI can have multiple responses in a single transaction, and those responses do not all have to go to the same queue or use the same think time.  When you use the think time in your VSI then that enables the ability to send the responses in a background thread, while the VS thread goes on to handle the next request.  This greatly reduces the capacity your VS needs in order to handle any kind of load.

However, if you go that route then you will have to use the newer 'IBM MQ Native' protocol rather the the deprecated 'IBM MQ Series' protocol.  The latter cannot simultaneously support both background thread think time and variable response queues.