VS is taking more time to send Sync Response

[Sai Kiran]

Hi Team,

During load test we could see one of the stub is taking more response time to send Sync Response. Stub will receive XML as input, XML contains data(Like Zipcode, House No). Stub is designed to check test data DB table for match (of Zipcode,House No). Based on the Match or No Match VS will send the XML response.


Capacity : 90
Think Scale : 0
Think Time Spec : 400

[Danny Saro]

Hi,

I am assuming you are running this against a Perfomance VSE, right?

In the past it used to be, and to my knowledge it currently still is, that a Performance VSE is only certified against the OOTB VSMs. Meaning, only expected to run with VSMs they are created with VS Model style "More Efficient". Once you adapt the VSMs workflow the performance of the virtual service is undefined.

That being said, as you have adapted the VSM, is the think time of all the additonnal workflow steps that you added set to 0? (Because by default any step you add to VSM gets a 500 - 1000ms think time).

When you run a testcase against this virtual service outside the context of the load test, what is the baseline response time?






------------------------------
Cheers,
Danny
------------------------------

[Sai Kiran]

Hi Danny,

Thanks for your reply.

Yes, we are using performance VSE. 

Think time of all the additonnal workflow steps were set to 0.

The baseline response time outside the context of load test is 0.5sec.

[Danny Saro]

Hi,

You would have to determine which step in your VSM takes up the bulk of that 10 to 20 seconds of "run time". I would suspect it is the DB query? Is it a production-grade DB, sufficiently scaled for the required number of transactions per second?

The best practice for backend service virtualization to support load and performance tests on your SUT is to select a discrete amount of relevant tests such that the number of back-end responses is limited. And then have those responses available in a vsi, such that every request can be handled in memory within the VSE. We call it a best practices but it is just common sense and logical that this would result in a vs with the highest throughput. In the past there used to be a product statement that a performance VSE was only supported to work with OOTB VSMs (VS Model style: more efficient, and configured with execution mode "EFFICIENT".

It might very well be possible to get your VSM to perform well but as it is custom there is little advice we can give on what to do.

------------------------------
Cheers,
Danny
------------------------------

[Sai Kiran]

Hi Danny,

Can you help me with process/approach to capture the individual VSM step 'run time' during the load test.

Best,
Kiran.

[Danny Saro]

Hi,

 

The way I understand it you are searching for confirmation that 1 particular step or a combination of steps takes up the bulk of the virtual services' response time.

 

I assume that you have looked at the inspection view in the portal and perhaps could not find your custom step inside the "event details" pane? You can try to unselect "Quiet" for this step and the next one in the flow so they show up and you see the timestamps of execution?

 

Or, below would be just a quick and dirty approach that you can use to confirm the suspicion that the bulk of time spent is within some step:

• Add a timestamp filter to this step; select a date pattern that shows you seconds (or even milliseconds); select "Pre Process", as well as "Post Process", and give a relevant property name
• Add a Scriptable assertion to this step, if this step has multiple assertion then move it up so it is the first assertion executed.
• Set the assertion to "fail the test" on "false"
• Then add these 2 lines:

 

System.out.println("<name of the step> - Start:" + <name of preprocess ts property> + " Stop:" + <name of postprocess ts property>);

return true;

 

• Now you can process the VSE log and filter out all lines that start with "<name of the step> - Start:" and inspect a few of them to have you confirmation

 

Hope this helps,

 

Cheers,

Danny

 

::DISCLAIMER::

---

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.

---