Tuesday 8 April 2014

What is a Transaction Response Time?

Transaction Response Time :

    Time taken for the application to complete a transaction or business process.

      Objective of measuring the Transaction Response Time – to ensure that the application is working perfectly under heavy load. However, the definition of heavy load may vary from system to system. In Loadrunner by defining an initial acceptable response time, we can benchmark the application if it is performing as anticipated.

      Measuring transaction response time is important as it gives an idea of how the aplication is performing in terms of time. This performance parameter can be related to the end users at the time of processing request. It helps in understanding how their application performed.

Transaction Response Time is the sum of
1. Time taken for the request made to the web server

2. Time taken by the web server to process

3. Time taken by the application server to process

4. Time taken by the database server to process

5. Time taken for the procesed request to come back to the client / user through various routes

6. Time taken for the request or data in the network transmission is also considered in this –Network latency between the servers and the client.

   Measuring Transaction Response Time in LoadRuner:

      It begins when the defined transaction makes a request to the application. From here, till the transaction completes before proceeding with the next subsequent request (in terms of transaction), the time is been measured and will stop when the transaction completes.
Does LoadRunner transaction response time include the rendering
time of the browser?

    NO, because LoadRunner is not designed for client-side activities.

Rendering time includes the time taken for the display of the web components, JavaScript or applet to load in the browser that is being activated after the HTML page is being received.


      When we replay the scripts in LoadRunner, network traffic are being generated by the APIs (functions) and are expected to receive before the subsequent step can be executed. All this are taken place in memory and what LoadRunner does is to generate the traffic and receive the responses in memory. No user interface (UI) is launched in the process of replay for the purpose of rendering the pages received. Having no UI launched, rendering is omitted.

      In a real user environment, the entire time for response in user perspective includes the request sending time, request processed time, response time and the browser loading (rendering time).

     However, in the context of LoadRunner, UI is not part of this entire request and response cycle.

       For an end-to-end response time testing that includes the rendering of the UI, we can use the GUI VUser protocol.

No comments:

Post a Comment