Higher response time in LR compared to manual run for 1 user

[Avisha]

Hi All,

I am running a load test on an application whose UI is on salesforce. I am observing higher response time in Load Runner compared to manual run for a single user 1 iteration in VuGen/Controller.

Manually, it takes around 12-15 secs to launch the application but in Load Runner, it goes up to 55-60 seconds. I disabled all logging ,excluded think time and all other activities from the transaction. The authentication used is SSO-based which always takes around 4-5 seconds, rest is just opening up the application. There are around 60 web_custom requests after the authentication part.

Can you suggest how to proceed.

[André Luyer]

Did you clear the caches before measuring the manual time?

60 web_custom requests: that is probably executed in serial. Is this also the case when launching the application manually? E.g use Wireshark to compare manually and replay.

Lookup web_concurrent_start or switch to TruClient.

André

[varun yadav]

All Page download resources should be within concurrent group. So that all requests hit the server simultaneously instead of sequentially.

Thanks,

Varun

--
You received this message because you are subscribed to the Google Groups "LoadRunner" group.
To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunner+unsubscribe@googlegroups.com.
To post to this group, send email to LR-Loa...@googlegroups.com.
Visit this group at https://groups.google.com/group/LR-LoadRunner.
To view this discussion on the web visit https://groups.google.com/d/msgid/LR-LoadRunner/e944a5b7-85d6-4915-9774-487f85c38080%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mital Majmundar]

Is the system loaded with concurrent users when you are taking the manual timings?

If not then i think you have a higher response time issue.

 

Mital Majmundar

--

[Avisha]

I had cleared cache before manual run. 

While manually launching the application,events on the launch page start showing up in chunks(there will be 10-100 events. It is a launch page which shows the events for the present day). The web custom requests are executed in a serial manner in LR.

I tried recording in URL mode too. I see that there are requests like .css, .png etc that are part of web concurrent start/end. The web custom requests are outside it. Even then I tried putting all web custom requests within web concurrent start/end and changed the mode of all requests to HTTP instead of HTML. But the response time is still high. I am not able to justify this LR response time.

While trying with truclient protocol, I see that it shows replay succeeded before the entire page is loaded(takes 6-7 seconds). It only waits till it finds the object used for assertion
  

I couldn't try wireshark as I'm not sure if my company approves of it. I am checking that with my colleagues.

Let me know if there is anything else I can try.

[Avisha]

I am opening only 1  browser session and tried it even when no other team was working on that environment. The time difference is huge, almost 3- times the manual time.

On Monday, January 30, 2017 at 6:53:15 PM UTC+5:30, Mital wrote:

Is the system loaded with concurrent users when you are taking the manual timings?

If not then i think you have a higher response time issue.

 

Mital Majmundar

On Fri, Jan 27, 2017 at 1:14 PM, Avisha <keshri...@gmail.com> wrote:

Hi All,

I am running a load test on an application whose UI is on salesforce. I am observing higher response time in Load Runner compared to manual run for a single user 1 iteration in VuGen/Controller.

Manually, it takes around 12-15 secs to launch the application but in Load Runner, it goes up to 55-60 seconds. I disabled all logging ,excluded think time and all other activities from the transaction. The authentication used is SSO-based which always takes around 4-5 seconds, rest is just opening up the application. There are around 60 web_custom requests after the authentication part.

Can you suggest how to proceed.

--
You received this message because you are subscribed to the Google Groups "LoadRunner" group.

To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunne...@googlegroups.com.

[Avisha]

I tried putting them within web concurrent requests and the mode of all my web custom request as HTTP. Still the time is same.

Anything else to look at?

On Monday, January 30, 2017 at 6:27:57 AM UTC+5:30, varun yadav wrote:

All Page download resources should be within concurrent group. So that all requests hit the server simultaneously instead of sequentially.

Thanks,

Varun

On Jan 27, 2017 8:42 AM, "Avisha" <keshri...@gmail.com> wrote:

Hi All,

I am running a load test on an application whose UI is on salesforce. I am observing higher response time in Load Runner compared to manual run for a single user 1 iteration in VuGen/Controller.

Manually, it takes around 12-15 secs to launch the application but in Load Runner, it goes up to 55-60 seconds. I disabled all logging ,excluded think time and all other activities from the transaction. The authentication used is SSO-based which always takes around 4-5 seconds, rest is just opening up the application. There are around 60 web_custom requests after the authentication part.

Can you suggest how to proceed.

--
You received this message because you are subscribed to the Google Groups "LoadRunner" group.

To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunne...@googlegroups.com.

[varun yadav]

Run with vugen

Run with controller

Compare.

If vugen too taking high time, then issue with the script requests designed.

If controller onlu takes high time, scenario taking time. And need to relook runtime settings, script loading time, load generator connection,  getting ready time.

Try running multiple iterations and see the responses decrease with further iterations?

Thanks,

Varun

To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunner+unsubscribe@googlegroups.com.

To post to this group, send email to LR-Loa...@googlegroups.com.
Visit this group at https://groups.google.com/group/LR-LoadRunner.

To view this discussion on the web visit https://groups.google.com/d/msgid/LR-LoadRunner/f8167393-104a-4020-884e-d09ec28a90df%40googlegroups.com.

[Avisha]

It gives the same time with vugen and controller.  The script only has requests that came up as part of recording.I have added correlations and some modifications is done to the authentication that were required for redirection.  My load generator is the same machine where LR is hosted. I cannot run multiple iterations because this authentication is a one time thing/user and if we refresh, it will redirect to the salesforce home page.

[varun yadav]

Check if any request is repeated in replay log. Adding time twice. While it should be once only.

You can compare no of requests in replay log, with manual browser login action with F12 developer tool option.

Thanks,

Varun

To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunner+unsubscribe@googlegroups.com.

To post to this group, send email to LR-Loa...@googlegroups.com.
Visit this group at https://groups.google.com/group/LR-LoadRunner.

To view this discussion on the web visit https://groups.google.com/d/msgid/LR-LoadRunner/e0c78628-85ca-4732-9264-c32f59250138%40googlegroups.com.

[James Pulley]

Load Generator on same host as controller is not a recommended practice.   The controller is a pretty busy piece of software and you will have to share your application CPU cycles.

Things to do: 

* manually execute your script from the MDRV command line.  Compare the times in the log to the times you see in the controller

* Move your load generator to a host independent of the controller.  Make sure it is a physical host and not a virtual machine likely hosted on an oversubscribed hypervisor

* VUGEN is slower for debugging purposes.  You can speed up VUGEN by turning off all logging, disabling any run time browser and animated replay.   Combine this with a run time flag for sensitivity of '0'

* your browser likely has elements cached that are requested anew with each iteration of your LoadRunner virtual user.  You can check the generation logs for those items which have cache headers and take that into consideration.


Are you sure you are measuring the same thing?  One is visual and the other logical (number of requests).  It is possible for items requested to still be in the download process where you do not see them because they are below the fold on your page.

Keep in mind, tools don't get very far if they are not representative of what happens in production.   The odds are high that you have a disjoint between what you are measuring in both cases which is the root of the perceived different in response time.

[André Luyer]

In order to find the cause of the difference between manual and replay you must be able to measure it. So if Vugen does provide the information (recording log vs replay log, etc.), then use any other means. What company will refuse you to do your job?

For truclient: if the automatic detected end-event is not correct, set it manually to the correct one. E.g. "Step network completed" or "Object Exists".

See http://tchelp.saas.hpe.com/en/12.53/Content/TruClient/procedures/understanding_end_events.htm

André

[Avisha]

I checked the requests sent manually from  F12 developer tools . They are the same. The response is also same.

[Avisha]

I will check executing scripts from MDRV command line(haven't tried).

I have executed the script from a physical machine,Blade machine and a VDI. There is negligible difference in timings.  Does the controller and LR host being same affect for 1 user/1 iteration?

 Maybe the browser has cached items which are newly requested every time during LR execution. You have mentioned  "You can check the generation logs for those items which have cache headers and take that into consideration." Can you please explain how to do that?

Also, you mentioned "It is possible for items requested to still be in the download process where you do not see them because they are below the fold on your page." How do I check this? This can also be the reason because for any request to salesforce ,there are many activities happening on the salesforce end.

[Avisha]

Haven't been able to look into the wireshark thing. Will check that too.

I tried the truclient with manually putting the end-event step. It does give proper response time but It cannot be used for a full fledged test.  It exhausts the system resources. A 10 user test for 1 iteration starts failing due to high resource consumption.