So you’ve been asked to run a Coronavirus inspired VPN LoadTest.

So you’ve been asked to run a #COVID19 inspired #VPN #LoadTest – just in case the whole organization needs to #WorkFromHome.

I’ve run multiple tests for various clients, with a similar focus, in the past, and thought it might be a good time to share a process that has worked well for me.

The Coronavirus has already triggered a massive Work From Home experiment in many regions, and many organizations are checking if they can support a sudden increase in remote access utilization. If you are the Performance Engineer that has been ‘tapped’ for such a special project, then these notes, which are based on my personal experience, may help you formulate and even execute a plan.

The goal of such tests is frequently to ensure that existing VPN aggregation solutions can support the increase in workload, both in terms of traffic and connections, so the approach simply requires a significant number of VPN connections generating a significant (and somewhat realistic) traffic profile.

To achieve this, I have built tests that are basically variations on the following:

Set up a vanilla web site in the protected ‘corporate’ network.

• This web site will take the place of all of the systems to be accessed by 'remote' virtual users. By hosting random manufactured content, and limiting (test) VPN access to this single resource, the technical risks for the test can be well managed, and scripting is kept very simple and data issues are eliminated.
• Configure the web site with a resource that is easy to change, that contains a single number, between 0 and 100, which will be referred to hereafter as ‘Current Workload Percentage’. For example https://<host>/workload
• Load the web site with a large number of files of various sizes. (e.g. 1,000 10K files, 1,000 50K files, 1,000 100K files…..) Use a naming convention that makes sense, such as Random_xxx_nnn_sssssKB where ‘nnn’ is a number from 000 to 999 and 'xxx' indicates of the contents is Compressible Text or Compressed or whatever and sssss is the size of the file in KB. Note that a file containing a million 'A' characters will compress very well, and will probably not contribute to a meaningful network workload mix. I usually write a dedicated script to produce a set of files for such tests, based on the actual requirements.
• Enable logging on the web server, so that post test analysis can be performed on the logs, as required.
• Set the ‘Current Workload Percentage’ to 0, so that no data is generated by any clients until you are ready.

Create a base image with your preferred Cloud Provider that contains the following:

• VPN Software that automatically establishes a connection to the required VPN endpoint, configured with the required security / certificates / credentials. This may require some technical creativity, but it is important that the connection is established after a short delay, such as a minute, as external connectivity to the instance may not be possible once the connection is established. You may need this window of opportunity to login to the instance to reconfigure it.
• Make sure that the VPN connection uses the configuration that is to be used by real clients.
• Build a simple Script that runs once a minute, reads the Current Workload Percentage from the above mentioned web site and then runs ‘n’ loops.  It can be as simple as a cron initiated script that runs curl statements. For each loop iteration, get a random number from 1 to 100 and execute the required ‘workload statements’ if the number is LESS THAN OR EQUAL TO the Current Workload Percentage. It is important that all of the activity generated by this script should be able to be completed within a minute, even under difficult circumstances. The script should include a relevant mix of GETS and POSTS back to the central web server. The POSTS can have very large bodies if upload bandwidth is important. The web server needs to accept the requests, but does not need to actually process them.
• If you want to get a little sophisticated, then you can embed local time and other information into formatted requests, so that you can determine response time behavior by analyzing logs after the test is complete.
• Make an image of the instance after checking that everything starts and runs as expected.

Test Your Base Image

Launch the image, as a single instance. If the above steps are performed correctly, then you should see the instance connect. Then update the Current Workload Percentage on the main web server to 100 and the web server should, within a minute, be receiving requests and delivering responses.

Launch a second or even third instance, checking that everything is working as expected. Use this opportunity to work out the appropriate ‘Current Workload Percentage’ that should be used.

When I have run these types of tests, I usually have two or three 'flavors' of base image. One might represent a 'power user' and another might represent an 'intermittent user' and another may represent a 'small office' of users.

Now for the real test.

Adjust the Current Workload Percentage to a sensible starting value.

Launch as many instances as you need to meet the test requirements.

Watch and learn. Stop and restart instances as required and adjust the ‘Current Workload Percentage’ as required.

Leverage your cloud monitoring to measure traffic flows, the web server log to measure latency.

I understand that this approach is very simplistic, but if you are asked to quickly pull together and execute a VPN test, then this may be a good place to start.