Load Testing Projects
This guide builds off of basic information contained in our AEE explainer and the Set Edge Locations guide. We will also refer to parameter values that are catalogued here. Please familiarize yourself with those documents before proceeding.
In the Set Edge Locations we recommend that you start out using a static policy in your LocationOptimizer ConfigMap. This is how you will be able to control where your Project is deployed in the absence of traffic. The following information will help you build confidence with a dynamic policy and load testing.
Things to Keep in Mind
The traffic signal, described here, is smoothed. This has 2 impacts on load testing. First, it dilutes small, brief spikes. This is desirable in production, but it means small, brief blips of traffic will not result in very high traffic rates due to the smoothing. Second, if you switch load source locations abruptly, the traffic signal will smooth that out over the span window. You will have to wait while the signal from the first source location decays and that from the second source location grows. An effective load test would aim to deliver a strong signal (10+ rps) over a reasonable duration (5+ minutes) so that your signal is clear. You would then wait approximately 15 minutes before sending traffic from a new source location. The traffic rate you simulate needs to also account for the minimumUsagePerLocation.
The minimumUsagePerLocation parameter exists to dampen the reactions of the AEE:LO to minor variations in traffic rate and location. Generally, we do not want to spin up in a new location due to a trivial increase in the traffic rate from some distance source. For production traffic, the default of 20 rps has proven to be very valuable and effective. For load testing, you may want to reduce this to 0 to make the system maximally sensitive to the traffic you generate. Again, this is likely too sensitive for production use as it will result in thrashing, but could serve well in load testing.
The minimumLocations is another important parameter for production traffic. However, to most clearly see the impact of a load test, you might consider setting this parameter to 1. This way, the selected locations will be more directly attributable to your test traffic.
Load Tests vs Production Traffic
Load testing typically involves sending traffic to your Project from one location. Production traffic typically originates from thousands of different geographic locations simultaneously. It is difficult to evaluate the complex, dynamic response of the LocationOptimizer. As with all good testing, we will show you how to partition out and simplify your ConfigMap in order to evaluate it under even a simple, single-source testing scenario.
First, consider this ConfigMap:
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic",
"mustInclude": [
{
"region": "europe"
},
{
"region": "northamerica"
}
]
}
}
metadata:
name: location-optimizer
This specifies 2 locations, in Europe and North America, and the implicit default value for the minimumUsagePerLocation parameter is 20 rps. Now, suppose we want to test this ConfigMap using a tool like ApacheBench and a VPN. Let's say we want to see a location spin up in Asia, we simulate traffic from Singapore.
Under these conditions, we will only see a new Asia location in the solution if the load results in 60 rps or greater in the traffic metric over several minutes. This is because we require the European and North American locations. For the given value of minimumUsagePerLocation, we will only get a third location if all existing locations can serve at least 20 rps, so it is only when we hit 60 rps that a third location is warranted. At that point, the location of the traffic finally starts to impact my solution and we should get a location close to the load test origin.
So we need to make sure we send a lot of traffic, or we could tailor the ConfigMap so that the solution is more sensitive, as illustrated in the examples below.
Examples
The following ConfigMap will give a very quick response to simulated traffic from anywhere outside of Europe:
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic",
"mustInclude": [
{
"region": "europe"
}
],
"minimumLocations": 1,
"minimumUsagePerLocation": 0
}
}
metadata:
name: location-optimizer
The ConfigMap above will require at least one location at all times and that one location must be in Europe, even in the absence of traffic. This is a nice way to ensure that you know where your Project will be running while you prepare to simulate traffic. We can now examine two aspects of the configured behavior with a few different load tests.
First, we can simulate traffic from various locations inside Europe and see the one location moving to be close to the traffic source. If you are switching the source location of your load quickly from one place to another, you may have multiple traffic signals due to the inherent smoothing. This would result in multiple locations being selected, with a new one added with each new traffic signal location. Because we reduced the minimumUsagePerLocation to 0, we can expect to see new locations spin up near any source of traffic.
Second, we can simulate traffic from outside Europe and we will see a nearby location spin up, while we also maintain a single location in Europe.
Apache Bench (ab)
Apache Bench is a tool for benchmarking HTTP servers. You may find it useful in generating traffic against your new CloudFlow Project so that you can observe the behavior of the AEE. When you use a tool such as this, make sure that you are generating enough traffic relative to your minimumUsagePerLocation parameter, as discussed earlier. Use the -c concurrency argument to generate multiple requests at a time, using 10 or more as the concurrency value. For example:
$ ab -n 10000 -c 10 https://myenv.myapp.com