Forum Discussion

AlexKaras's avatar
AlexKaras
Champion Level 3
9 years ago

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

Hi,

 

The question was inspired by the "LC 4 - huge variance in page load times between LC4, LC3 and IE" thread (especially, http://community.smartbear.com/t5/LoadComplete/LC-4-huge-variance-in-page-load-times-between-LC4-LC3-and-IE/m-p/114875#M1248 and later).

Comments and corrections from Ryan and community are really welcome.

 

So, based on https://support.smartbear.com/viewarticle/78623/, there are three think times distinguished by LoadComplete:

a) Page Think Time - this is the time spent by the user reading and working with the current page;

b) Connection Think Time - this is the time passed since the browser started to download the page and opening additional connection(s) to web server to speed-up download of the additional resources required by the page. If more than one additional connections are opened, each of them has its own think time;

c) Request Think Time - this is the time passed between the end of one request and start of the next request issued within the same connection while downloading the same page.

 

Everything is more or less clear with a) and c) think times:

-- Page Think Time is completely determined by the end-user and can be set according to the usage statistics from production web server or according to the general expected end-user behavior. Increase or decrease of the Page Think Time effectively simulates how long end-user stays on the page;

-- Request Think Time, on the contrary, seems to be completely the internal matter of the web browser - it is up to it to dispatch requests by existing connections - and seems have no reason to be adjusted.

 

But Connection Think Time is something that is not completely clear to me at the moment.

It is my understanding, that the necessity to open a new connection is determined by the browser while parsing and processing already downloaded resources. This means that the delay to create a new connection (i.e. - the value of the Connection Think Time) is determined by: a) the connection speed; and b) the speed of resource processing (actually - by the time spent to execute associated jscript code).

If the above is correct, this means that adjustment of the Connection Think Time simulates the speed of connection (which is expected to be controlled by the Connection Speed parameter of the test setup, accessible in the Test Editor window) and the computational power of the client machine.

So, if I see a big value of the Connection Think Time on the Timeline tab for some secondary connection and this connection starts after the initial connection (the one that started download of this given page) was closed, for me this is an indication that it took a lot of time for the client browser to process the initial page resource. If I like to emulate a more fast client environment, then I may adjust the value of the Connection Think Time for this secondary connection.

 

Any comments on above?

Any ideas/experience about when adjustment of the Connection Think Time might be useful and what this suggested adjustment means from the process flow point of view?

Anything else I might miss?

  • RyanHeidorn's avatar
    RyanHeidorn
    Staff
    9 years ago

    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,

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3
      9 years ago

      Hi Ryan,

       

      > Thanks for the food for thought [...]

      Thank you for replying with the same :) - I carefully read your detailed answer and it inspired me for some more thoughts in the course of asynchronous staff (AJAX,  WebSockets, ...) mentioned by you and "offsets" concept.

      I would appreciate if R&D can provide their comments on the matter and still have the topics to consider meanwhile to get a full picture of how this part of LoadComplete works.