When we think of performance testing, often the first thing that comes to mind are highly scaled systems generating as much traffic as possible. This is done because we consider the most extreme conditions a production environment will encounter is when many users (or a coordinated attack) converge at once. However, extreme conditions can also be encountered at the other end of the spectrum with poor quality network connections. For example, a RedLine13 customer discovered that they had a number of production devices in exceptionally poor signal areas that were making API requests into their system via mobile networks. They were arriving at rates of bytes per minute which effectively locked up their system with what was effectively a Slow Post DDoS Attack. In this post, we will describe how RedLine13 can be used to simulate slow internet connections with JMeter.
In its default behavior, JMeter will send requests defined by its samplers as fast as it can. This is desirable for producing maximal load, albeit not entirely realistic as real users (usually) don’t hammer the server non-stop. If we consider mobile users who are limited by network bandwidth or even hampered by poor network signal we will notice a different performance profile. Similarly we might encounter the same type of instability for high-latency connections that send data in short bursts with long delays in between.
This exact case is covered in the Apache JMeter documentation here. There is a built-in “CPS” (characters per second) rate limiter that can be configured through the user.properties file. We are interested in the following two properties:
- httpclient.socket.http.cps, and
- httpclient.socket.https.cps
These values are set for http or https requests respectively. Subsequent requests will be limited to those character per second rates. There is also a formula which is covered in the JMeter documentation that can calculate a specific bandwidth as a CPS value:
CPS = (target bandwidth in kbps * 1024) / 8
Here is an example calculating a CPS for a target bandwidth of 500kbps:
CPS = (500 x 1024) / 8 CPS = 512000 / 8 CPS = 64000
Therefore in our user.properties configuration we would need to set:
httpclient.socket.http.cps=64000 httpclient.socket.https.cps=64000
There are two easy ways to configure this in RedLine13. The first is to supply your own custom user.properties file, which we provide under “Advanced JMeter Test Options” when starting at test:
A second (and probably more convenient way) is to specify these properties in a JMeter option string. You can do that from within the “Option String” text area under the same “Advanced JMeter Test Options” section:
Let us take a hypothetical sample test and experiment with CPS settings. We can select a pretty low value of 7600 which will simulate an extremely latent and/or unreliable WiFi network. We can set our JMeter options string to contain the following settings:
-Jhttpclient.socket.http.cps=7600 -Jhttpclient.socket.https.cps=7600
Here is the original example test completing in a few seconds:
After applying the options string, here is the throttled test (where CPS = 7600) which takes much longer. In fact, approximately half of the requests are dropped due to timing out:
You can adjust the CPS to any value which will mimic the slowness of your simulated latent or otherwise poor quality network connection, simply by specifying these values in the options string.
RedLine13 offers a full-featured free trial which will allow you to replicate the steps outlined in this post to load test simulate slow internet connections with JMeter. Sign up now and get started today!