Uh oh! My server name is changing.
You have been developing performance tests for 6 weeks, 6 months, or 6 years, against your server application. Suddenly, your IT group announces that the server is going to be replaced with a different server, one with a new name and a new IP address. From the time that you have spent staring at performance tests, you know that you can see the server name(s) right there on every request line. What are you going to do if that changes?
The Scenario
We’re going to use a very simple example. You work for Google. You are assigned the task of testing search response times for the Google search engine – www.google.com. You generate many tests against this server, including a search for an individual name.
Such a test looks like this at its top:
You can plainly see the purple/lavender highlighting on numerous requests directed to www.google.com.
The only constant in life is change. Your boss lets you know that, starting next week, you will have to start testing Google’s Canadian-based search engine – www.google.ca.
The Mechanics
You have an existing test that works against www.google.com. Can you make it work against www.google.ca?
The process is simple. Let us recall the www.google.com test displayed in “The Scenario” section. There were numerous occurrences of “www.google.com” requests. They were, in part, notable because they were highlighted in purple/lavender. The purple/lavender color scheme is indicative of a substitution point. That means the string you see highlighted is a placeholder; the actual value is set earlier in the test.
How can that be as these requests are the very first thing that appears in the test? Well, that is not quite true. There are Test Variables that are defined under the Test Resources section at the very beginning of the test.
Among those Test Variables is an entry for each host/port combination that appears in the test. In the example, there is only one such pair. The variable “Search4Name_Host” is the point where the literal server name is initialized.
Making a change, to use a new server name, means changing the “Initialize to” value from “www.google.com” to “www.google.ca”.
Something to notice as you make this change is that the purple/lavender highlighted text throughout the test DOES NOT CHANGE. A substitution point is a place where we will be substituting a value. In the original recording, that highlighted string happens to match the “Initialize to” value. Since it is just a placeholder, no effort is made to change it when the “Initialize to” value is changed.
You will see the change in the Test Log after you run the modified test; the server names will display with the modified value.
Why This Might Not Work
The single most important consideration as you go into this task is that you want the file systems on the two servers, in this case www.google.com and www.google.ca, to be identical.
Returning to the discussion of the Google search test, here is an example of what can go wrong:
The request displayed is a GET request seeking a specific file - googlelogo_color_272x92dp.png. The GET request includes a specific file system path - /images/branding/googlelogo/1x/ - at which to locate the file. This, of course is the location of the file on www.google.com.
If the application deployment on www.google.ca puts that file at /imagesNEW/branding/googlelogo/1x/, then the GET request will fail when after the server name is modified. The most likely result is a HTTP-404 error code, meaning the file was not found at the specified location. The playback engine recognizes this as an unexpected response code and the test fails.
The test can be manually edited to address the change in path, but how many other little differences are also present?
If the file systems on the servers are not identical, you are faced with a question: is it easier to make the necessary changes manually in the Test Editor or to record a new test against the new server? That answer is subject to your own experience and experimentation.
Flexibility
Obviously, there is some inconvenience if you have to edit the server name(s) every time you wish to switch back and forth from testing the US server to testing the Canadian server. Please consider this discussion to be a simplest-case example. To achieve greater flexibility in switching between or using both servers, you can make use of custom code or datasets within your test. Those topics are quite broad and will not be covered here.
A General Load Testing Caveat
For this or any other load testing scenario, be prudent in testing against only sites that are specifically relevant to your test and/or under your organization’s control. While you are recording a browser session, your browser is likely to communicate with a great number of servers (background noise). When you are done recording, you are presented with a Domain Selection screen. It is expected that you will prune the background noise from your test. Failure to do so can have consequences. Third-party sites are often unhappy if your load testing activity suddenly, unintentionally, sends hundreds or thousands of requests to their production servers. This can be interpreted as an attack and can result in a denial of service reaction.
Imagine you are on the IT Security team at Google. A performance tester in Rochester, New York, runs a 10,000-user performance schedule against their company’s accounts payable server. By accident, that schedule happens to contain a test with a single request to the Google server. 10,000 duplicate copies of that same request arrive at the Google server in a short period from the same network domain. It is not hard to envision that being interpreted as an attack.
Know the domains that are relevant to your testing scenarios.
#RationalPerformanceTester