In this blog post, we will show you how you can replay load test scripts that make use of the HTTP/2 protocol. Before we jump over to Silk Performer and show you the details, let's first discuss what HTTP/2 actually is. Revision 2 of the hypertext transfer protocol has been released in 2015, 16 years after HTTP/1.1. It is a major advancement compared to HTTP/1.1 - in essence, it provides for a considerably faster communication between client and server. This is due to a number of improvements - we're going to discuss the following three in this blog post:
- the single-connection approach
- the server-push feature
- and the binary format
We've picked these three HTTP/2 features, because they also manifest in your load test results, which we will see later on within TrueLog Explorer.
HTTP/2 uses a single-connection approach. This means that all communication to a particular server is performed over a single TCP connection that can carry any number of simultaneous communication streams, which significantly reduces connection overhead. In contrast, HTTP/1.1 uses multiple connections to send traffic in parallel, which causes a lot more overhead and thus means more load for a server.
And HTTP/2 is a binary protocol, which means that it is not human-readable but significantly more efficient and robust.
Preparing a project
Let's now create a sample project and record some traffic that uses an HTTP/2 connection: We create a new Web business transaction project in Silk Performer, give it a name, and enter the URL https://http2.golang.org/gophertiles. This is an HTTP/2 testing site. There are two important things you should keep in mind when working with HTTP/2: (1) HTTP/2 mandates a secure connection, thus the URLs have the prefix https://. (2) the Silk Performer recorder actually forces a browser to use HTTP/1.1 during recording. In general this is no problem. We can later specify to replay the script using HTTP/2, which is perfectly fine for the actual load test.
We start the recording and Internet Explorer appears. The test page contains an image that is made up of tiles. The tiles are loaded successively, which allows us to see differences in connection speeds. You can click the links on the top to load the image with different HTTP settings. This way you can easily compare the loading speeds. In our example however, we will not perform any additional user interaction. We just close the browser and stop the recording. That's all we need to record for this use case. To complete the recording process, we click Generate script on the Capture File page.
We will now create two profiles with different HTTP settings: one for HTTP/1.1 and one for HTTP/2. Next, we will perform a trial run with both profiles, which will allow us to compare the different results within TrueLog Explorer.
But first, let's take a look at the initial profile (Profile1) that was automatically generated when we created the project: We double-click the profile and click Web (Protocol Level). Here we can set the Browser and the Preferred HTTP version. We will go for Internet Explorer 10 and HTTP/1.1, because this is the default HTTP version for IE 10. We click OK and rename the profile to HTTP 1.1. We now have to make sure that our script does not contain a WebSetBrowser() function, because this function would overrule the settings configured within the profile. In our case the script contains the following line:
We remove this line so that the profile settings are used for replay. Now we create a new profile and name it HTTP 2. For this profile we set IE 11 (1) and HTTP/2 (2), again, because this is the default HTTP version for IE 11. If you're not sure what the default HTTP version of a certain browser is, you can click Details (3). Here you can see the Supported HTTP version (4), this is the default. You can also see in the profile settings that we can separately switch on and off the option to fallback to HTTP/1.1 in case the server is not capable of HTTP/2 communication (5) and the server push feature (6).
Performing a trial run
So, we've prepared our two profiles. Now we make sure that both profiles, or more specifically both user types, are added to the workload: We click Define user types on the workflow bar and move both user types from the left to the right list (User Types in Workload).
Normally, we would now start a Try Script run to verify that the script works as expected. However, a Try Script run only uses one user type and will only output one TrueLog. What we need is an execution that uses both of our user types and outputs two TrueLogs that we can compare. This is exactly what the Try Agents workflow step does, so we click Try Agents on the workflow bar and start the execution.
When the execution is completed, we can open both TrueLogs in TrueLog Explorer and compare them.
Comparing the TrueLogs
For an effective comparison we can use TrueLog Explorer's compare view, so we move the HTTP/2 TrueLog to the lower pane. Additionally, we switch on the Synchronize feature. On the Statistics tab, we can compare the metrics.
Here are the differences for our example:
- the page time for HTTP/1.1 is 3410 milliseconds (1)
- the page time for HTTP/2 is 1834 milliseconds (2)
So as expected, the HTTP/2 is definitely faster for loading the image on the test page. The colored bars show that for HTTP/2 only one connection has been established (3) and that this connection was then used for a number of communication streams in parallel (4). In contrast: For HTTP/1.1, 12 concurrent connections have been established (5), which were then used to send and receive data sequentially (6).
Analyzing the server push feature
For this demonstration, we have also recorded a page on the above mentioned testsite (https://http2.golang.org/serverpush) that incorpartes the server push feature. We've then repeated the steps described above to create two TrueLogs that we can compare. So, let's have a look at those in compare mode. The first thing to note is that the nodes in the tree show what resources have been pushed by the server (1). And again the Statistics tab provides some more interesting data: It shows that the transmission for four resources has started (2) before the initial request has been completed (3). This also clearly indicates a server push behavior.
This is how you replay HTTP/2 load test scripts with Silk Performer. Keep in mind that currently Silk Performer uses HTTP/1.1 for recording and that you have to use a secure connection when you record your script. Test the options within the Profile Settings and then analyze your results within TrueLog Explorer.
Watch the video
To learn more about all new features and enhancements Silk Performer 19.0 provides, take a look at the following blog posts:
The Silk Performer Help is another comprehensive source of information.
If this article was useful for you, leave us a comment or like it. We appreciate your feedback.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.