High think times on each page's connections

As far as I know there are two ways to fix your problem:

Clear think time - you can right click on the scenario in the scenario editor and click clear think time; from my understanding this will set all think time to 0, although I have never tested it before.

Change think time in the test - open up your test. At the bottom there should be a tab that says think time; you can choose to use a random think time and set a range, for example you could do: use a random think time from 0 to 1,000 ms.

I don't know of any other ways to fix your problem; but that doesn't mean there aren't any other solutions. If neither of these work for you, you could always try looking through the LoadComplete documentation.

Hi,

I might miss something in your problem but I tend to agree with Wesley.

Also the possible ways to change different think times are described here: https://support.smartbear.com/viewarticle/78623/.

As a side note: while it is possible in LoadComplete to adjust values of different think times (page, connection and request), the most relevant and worth correction is page think time. (In case your web application uses the same page but updates it DOM via ajax, then you should use custom pages while recording the traffic (https://support.smartbear.com/viewarticle/78863/).)

Indeed, the purpose of LoadComplete is to simulate web traffic generated when the tested web application is used by humans. (While SoapUI + LoadUI (https://smartbear.com/product/ready-api/loadui/overview/) simulate load for web services which (load) is not necessarily generated by humans.)

This means, that main delays in the traffic are caused by the time that the human spends on the page, reading it or providing input data. This is the parameter that is worth to be adjusted to emulate that some people read/type faster and some do the same a bit slower.

Then, when he/she is ready, human clicks something on the page that initiates transition to the next page. The primary request is send to web server and web server responds with the next page. Upon obtaining this new page, browser starts to process it and submits additional secondary requests if some additional data (scripts, images, etc.) are required by the page.

Note, that the time intervals between these additional connections and requests (their respective think times) do not depend on the end-user but are a function of how fast the initial page is processed by the browser and how quickly previous secondary requests are executed.

The above means that if I see a long think time between secondary requests created during page load, I would not simply manually decrease their think times, but analyse the possible reason(s) of why think times are that long.

For example, it may be that some big script file is requested somewhere in the page and browser waits until this file is obtained. You may talk to your developers / web server administrators and consider minification and/or compression and/or split large file on several smaller ones and load only really requred one(s) as a possible solution. Once obtained, the browser starts executing script file and it is possible that script code does some long running operations that extensively modify page's DOM. You may use, for example, AQTime profiler (https://smartbear.com/product/aqtime-pro/overview/) or built-in browser profiler to hunt for the page script code performance problems.