Understand Response Time Statistics for Pages in HCL OneTest Performance Testing 

Abstract 

For HTTP-based web applications, an end user’s perception of performance is typically based on page load time on the client. Browsers, which remain widely in use, do several things to make this efficient. HCL OneTest Performance captures several aspects of a browser’s behaviour and models that into a “Page” container in test scripts. Consequently, the response time statistics reported by the product for pages is more than a simple aggregation of response times of individual HTTP requests. In this blog post, we understand what really drives the user’s perception of application performance and learn how HCL OneTest Performance’s Page models that.

The era of web applications and the browser

The explosive growth of the Internet witnessed in the last two decades has led to a proliferation of applications and technologies. Amidst the spirited innovation in distributed computing, some experiments have emerged victorious. A frontrunner among them is HTTP-based web applications, which are modelled in the client-server paradigm and accessed from a browser. With a large share of users on mobile devices using either browsers themselves or hybrid apps that embed a browser, one could argue that this paradigm has plenty of shelf-life left. In other words, the browser’s reign as champion is far from over. Accordingly, for performance testing products, mimicking the browser’s ways remains to be the best choice for creating realistic loads and getting precise performance metrics.

A case for considering a page navigation as a specialized transaction

Performance analysis has always centred around a triumvirate of measurement types: response times, throughput, and health. Any attempt to analyse an application’s performance, without looking at all three in unison, is futile. To capture these measurements in a meaningful sense, performance engineers typically employ an aggregation device for a group of requests. An entity called “Transaction”, with its DBMS-inspired implications of atomicity or indivisibility, is a popular device for grouping. A transaction, in the eye of a performance engineer, is a chronological sequence of requests or exchanges between the client and the server that is necessary to complete a business flow: to deliver a unit of work for an end user. A typical performance tester is accustomed to eyeballing their test script to identify requests that belong together, and then define transactions to group them. But is this needed for web applications? Do the benefits of this exercise justify the efforts? The answer to both questions is, thankfully, a resounding no. Let’s see why.

In the world of web applications, a page navigation triggered by a user can itself be viewed as a transaction: it completes a unit of work and is indivisible. Page navigations include: hitting an application URL to launch a home page; submitting input data in forms, such as entering login credentials, filling in search terms, etc.; and clicking hyperlinks; These page navigations typically result in a flurry of browser-triggered activity at both the client- and server-ends. From the client’s perspective, these include issuing requests to the application server for content and processing the received content to render so that the user has everything they need for the next interaction. The application server is even more busy; it has the onerous responsibility of preparing the content the browser client is asking for. In summary, there is a clear sequence of events, a duet-dance between the client and the server, that completes a certain unit of work. Furthermore, after each page navigation is a period of noticeable quietness (in the wire); that not only gives further credence to treating individual page navigation as a collective unit, but also acts as a marker for performance testing products — like HCL OneTest Performance — to identify boundaries of separation.

Contrary to what is commonly regarded, the time taken to complete a page navigation is seldom a simple summation of response times of individual requests. As we saw earlier, there is involvement of two separate actors – the browser client and application server – in this complex endeavour to complete a page navigation. It follows that the time taken to complete a page navigation is influenced by several factors including, but not limited to, the browser’s optimization strategies and processing times, the server’s processing times, and network latencies. Therefore, for accurate analysis, depicting a page navigation as a simple aggregation of back-to-back requests will be naïve; a page navigation needs a superior, tailor-made abstraction. HCL OneTest Performance does this through an entity called — Page.

A user’s perception of application responsiveness

This argument is perhaps better appreciated with a deep-dive into the events that take place when a user initiates a page navigation. The sequence of events is started with the initiation of a TCP socket connection between the browser and the application server. A new connection request would entail a Name Server (NS) Lookup, a TCP handshake and if necessary, an SSL handshake. After the connection is established, the browser issues an HTTP request to the application, typically for the main HTML content for the new page. Once the browser receives the content from the server, it starts a pre-loader process to spot the required secondary assets for rendering the page: assets such as scripts, stylesheets, images and fonts. With an aim to utilize resources efficiently, the pre-loader may employ concurrent connections for these requests, where one connection could be reused for multiple requests. In parallel, the browser also starts the loading process to build the required object models (document and CSS) by parsing through the HTML content received at the beginning. When the server responds to the pre-loader’s requests for the secondary assets required by the page, the browser wraps up the loading process by performing another round of activities such as compilation of scripts, preparation of CSS models, and execution of required script functions (which could result in some additional requests). The page is ready for the user to perform the next interaction only after the browser completes these activities.

It is at this point that an end user will feel that their navigation is complete. Hypothetically, if the end user started a stopwatch when they started the navigation and stopped it when the page was ready for interaction, the measured time would be the response time they perceived for the navigation. Included in this measurement would be: the time taken for establishing connections, delays due to network latencies, the time spent by the server processing the requests, and processing delays while the browser is working. The total time measurement, however, due to the concurrency of processes and requests would not be a simple aggregation of all these timings. Accordingly, a performance testing product, if it were to realistically portray performance, must mimic the browser’s behaviour for page navigation, and then measure and report that.

How a page models a browser’s page load sequence

Let’s first understand the structure of a Page in HCL OneTest Performance. A Page contains a bunch of Page Elements (HTTP Requests) out of which one is tagged as primary. The primary request is typically one of the earliest (if not the first) requests sent by the browser to the application server to get content required to initiate page loading. The remaining requests in the Page — which are referred to as secondary requests — are mostly those sent by the browser’s pre-loader to fetch other assets like scripts, stylesheets and images required to complete rendering the new page. All requests in a page are distributed amongst a set of “connection configurations,” typically in a many-to-one basis mirroring the browser’s pre-loader. Furthermore, requests that are sent through the same connection are time-spaced using a client-delay parameter.

To gather these parts and assemble them, HCL OneTest Performance records not only application traffic but also pertinent details of underlying TCP sockets through which it was exchanged. Alongside, it also notes the periods of stillness on the socket streams and their durations to deduce the time the browser spent on client-side processing. In addition, the captured recording session, which is used to generate test scripts, also contains the details of connections and the sets of requests that were sent on each of them.

While playing back a test script as each individual virtual user, for each page HCL OneTest Performance keeps track of the instant at which the first request was made (typically when the connection was opened if it is the first page) and the instant at which the last byte of the last request in that page was received. The final response time calculated for a page is the difference in time between those two instants. By mimicking the browser’s behaviour in the structure and timing of requests, HCL OneTest Performance measures and delivers a “response time” metric that’s realistic: as near it can get to the time-to-interactive (TTI) that an end user would experience.

Response time – contributors

Though HCL OneTest Performance’s view of web application performance testing is defaulted to center around pages, it does aid you in drilling down and looking at what factors contributed to an overall response time. The product’s feature-rich and intuitive reports provide easy options to examine individual page response times and its contributors such as: connection times, page element (request) response times, and client delays.

Conclusion

In this post, we understood why HCL OneTest Performance considers the sequence of events that occur during a user navigation as an indivisible entity: a default transaction. We learned the structure of a Page in HCL OneTest Performance and how it meets the end goal of browser fidelity: collecting a response time metric that’s as close as it can get to the response time experienced by an end user on a browser.