Load Testing MobileFirst Adapters with JMeter
MatthewCousens 0600013BR0 Comments (2) Visits (5867)
written by Torin Reilly
posted by Matthew Cousens
IBM MobileFirst provides an excellent framework for rapid assembly of robust mobile applications. MobileFirst Studio even includes a simulator which allows for testing directly in your browser. But what do you do when you wish to test the application at a production scale before releasing it into the wild? Apache JMeter allows you to do just that.
JMeter is an application that allows you to load test your web-based applications over all the common web protocols. In our case we will use JMeter to drive the HTTP requests of a MobileFirst Application.
Our JMeter script will be driving the EGUI MobileFirst demo application (located here) but it can easily be adapted to drive any MobileFirst application.
This document was prepared using Apache JMeter 2.13 and IBM MobileFirst Server 7.0 (v6.2 was also tested). JMeter can be found at http
Initially setting up JMeter is pretty straightforward. Visit the JMeter website to download the binaries and for documentation on how to invoke the application. You’ll want to start your JMeter script by pointing it to your MobileFirst Server.
Pointing JMeter to your MobileFirst Server:
Setting up the correct headers for our requests:
MobileFirst Server expects certain information to be in the header of the requests it receives. Luckily this information is mostly static, so it doesn’t need to be changed after it is first set up. Because this is defined at the topmost part of the tree this will be in the scope and used by all the requests we send below. Below are the fields MobileFirst Server expects to receive:
Most of this information can be copied verbatim, with the exception of a few fields.
Where you see “Origin” set that to your MobileFirst Server IP and port number (htt
Next, where you see “Referrer” put the server IP, Port, and path to the default preview of your app. The URL should be structured similarly to this depending on the path where you deployed your app: http
The final field, WL-Instance-Id is set to a variable called instanceid. This piece is used for session tracking and we will learn how to populate this variable later in the post.
Arguably the most important feature of JMeter is the Thread Group node. The thread group allows you to simulate the users that will drive your app. Within thread group there are a few options you may set. First is threads, which is essentially the number of users you wish to simulate. The next setting is ramp-up time, which just means how many seconds JMeter will take until it reaches the maximum number of threads you specified. This way not all the threads will begin executing at the same time and will be staggered much how actual users using an application are. Finally is loop count, this specifies how many times each thread will execute. This can also be set to forever if you wish to run an open ended test.
Sending a Request and initializing MobileFirst:
Defined within our Thread Group, HTTP Request Samplers represent the actual requests we wish to send. If you have set a HTTP Request Default in the proper scope, you don't need to duplicate the information here. You can also define what type of HTTP Request it is, whether that be a POST, GET, or otherwise. Typically if you've set the IP or address and port number, you only need to define the path the request is being sent to. This is also where you set any parameters to be sent.
The first request we need in a MobileFirst User flow is the initialization. This sends an initial request to confirm a device is connecting and responds with a WL-InstanceId which we need to keep track of each session. The path should be set to /wor
If you are not using EGUI the path will be similar but where you see “EGUI” you should replace that with the name of your application.
If you run the test plan now by pressing the green arrow and select the “View Results Tree” node towards the bottom of the test plan you should see init with a green check next to it.
Extracting data from a Response:
Nested under our intialization request node, we need to use a Regular Expression Extractor to pull data out of the initialization response and store it in a variable.
The Reference Name defines the variable to store the extracted value in so set that to something like instanceid. The Regular Expression we will to use to extract the value is "WL-
We use this method to extract our WL-InstanceID and store it in instanceid to be sent along with each request in the header. This will keep track of our current session. We then pass the value of that variable in our HTTP Header Manager.
Correcting Expected Responses:
Next we want to fix JMeter viewing this response as an error. To do this we will use a Beanshell Post Processor which basically just allows us to run some code once a request is executed. This post processor is defined under our “init” request, containing this code:
This will check for a 401 response code, which by default is normally considered to be an error, and mark it as successfully completed because that is the expected response in the initialization of MobileFirst.
Now that we have the initial “handshake” done, and the WL-Instance-Id stored for session continuity, we can begin to fire these adapters.
Invoking an Adapter:
Much like with our initialization request we must use an HTTP Request Sampler to invoke one of our Adapters. The only difference is there are a few parameters we must pass to specify which adapter we are invoking, as well as passing any required values to our adapter itself.
First, we must set the path. This should be in the format of (root directory of your app on mobile first server)/invoke. Next create a parameter called adapter and set it to the name of the adapter you wish to invoke. Then create another parameter called procedure which should be set the name of the function in the previously specified adapter you wish to call. Finally, add another parameter, confusingly called parameters, and set it to whatever parameters you wish to pass to your procedure. Make sure the “Method” drop-down box is set to the HTTP Request type you are using.