What might be the reason(s) to adjust Connection Think Time for the page?

Hi Alex,

Thanks for the food for thought — I spent a lot of "think time" considering my reply. :smileyvery-happy:

My first reaction is that request and connection think times might better be thought of as "offsets" than think time. The true think time is at the page level — as you said, accounting for the time a user may be viewing the page or inputting data. (Somewhat complicating this statement is the fact that a "page" in LoadComplete can be any arbitrary set of requests.)

On a generic level, request and connection think times are a way to manually control execution timings. Even if the simulation is not mimicking typical browser behavior, there are likely some legitimate use cases for injecting artificial wait times (for example, to test the behavior of asynchronous requests like AJAX or WebSockets). In the case of individual requests, a tester could control this behavior by manipulating request think time. I agree, though, that connection-level think time makes less intutive sense.

In the other thread you referenced, I noted that there was a bug in LC3 related to starting new connections for each page. I believe our developers implemented a connection-level think time to correct this behavior. The mechanism was not quite right in LoadComplete 4.0 and has been corrected in 4.1 — again, more of an offset than think time. I am not sure that a user would want to manually control these timings, though. I will see if our R&D team has any further insight into the matter, and will encourage them to post here.

Thanks again for the engaging question!

Best,