2. In the current digital world mobile app usage has overtaken
desktop traffic - and this trend just looks set to rise. But what
does this mean for us?
For performance engineers, it means that now, more than ever,
we need to focus on mobile users when running performance
tests. If our mobile app doesn’t perform well - our business will
be at stake.
3. In most of the cases, mobile device users access the
internet via the cellular network. The network coverage
will vary depending on the location. Hence it is very
critical to ensure that the system can fully handle mobile
and tablets - even when they have different internet
connection speeds.
By default, Jmeter will send the requests to the target
server as fast as it can. This is great for generating the
load on the server - but not very realistic as real users
don’t hit the server non-stop, they will have some time to
think between operations. On top of that, mobile users
are limited by network bandwidth, which can slow them
down considerably.
4. Option to throttle outgoing bandwidth in order to simulate different network speeds
Bandwidth can be controlled through these two properties:
◦ httpclient.socket.http.cps=0
◦ httpclient.socket.https.cps=0
“cps” stands for “characters per second”
The properties default to zero, which means no limitations
The formula for calculating “cps”
For example: to emulate the GPRS cellular network speed (which is 171 Kbits/second
downstream), the relevant CPS value would be: 21888 (171 * 1024/8)
cps = (target bandwidth in kbps * 1024) / 8
5. 1. Add these two lines to the user.properties file (you’ll
find this in the bin folder of your JMeter installation)
◦ httpclient.socket.http.cps=21888 httpclient.socket.https.cps=21888
◦ You’ll need to restart Jmeter to pick these properties up
2. Alternatively, you can pass the properties’ values via
the -J command line argument, like this:
◦ jmeter -Jhttpclient.socket.http.cps=21888 -
Jhttpclient.socket.https.cps=21888 -t /path/to/your/testplan.jmx