How to do Worklight Server performance testing
Eric__Wang 270003RTH1 Comments (4) Visits (6010)
The purpose of this document is to describe how to run performance tests on the different features of the Worklight server. In this post, jMeter performance test is adopted but for the other tools (Load Run etc), the steps are the same.
Worklight server features that affects performance
This document will describe in details the first two points. For all other points, please see references in the bottom of this document.
The realms that are part of the default security test for both Android and IOS and will be tested are:
When running performance test, your first step will be to finish with the authentication flow. If you will not do that, you will get security challenges and your requests will be rejected with 401.
This step includes sending init request to the Worklight server and extracting the relevant data from the response. The init request has the below structure:
The dynamic parameters in the Form Data (ski
Response data from Worklight initialization service
The response data from the Worklight "/init" is different based on the security test you applied on your Worklight application environment. By default, if you have no additional security test, the response data structure for “common” and “iPhone” environment are as below. (“Android” environment is the same as “iPhone”)
The difference is that “common” environment has no “wl_
Extracting the init response data
You need to extract the “WL-Instance-Id” and the “token” from the init response and send them as headers in all requests to the Worklight server. If not, the authentication check will fail and the request will be rejected. Challenge data is different for each session, so you need to extract and store the challenge data for each thread. See details in the backend invocation section below.
Change response status to HTTP 200
When the performance testing thread doing initialization on the first time, Worklight server will response challenge data with HTTP 401 status. This is as expect, so performance tool should treat this HTTP status also as success. The HTTP status can be changed to HTTP 200 by performance testing tool’s script. By this performance testing tool will record this request as success, or the performance testing report maybe mark this request as “failed” and record it as an error, this will highly impact performance testing report.
This step should come only after you finished with the authentication step. You can choose any type of backend that you want. The request for the backend invocation has the below structure:
Request to Worklight adapter procedure service
By default, the jMeter will encode the URL. If your performance testing tool does not support URL encoding, your will need to use the encoded value for parameters.
For “iPhone” and “Android” environment, since they contain the “wl_
When the response data contain “isSuccessful” true, that means you got the response data from Worklight Adapter procedure successfully and now your can continue with your backend testing.
When Worklight Adapter procedure is protected by security test or the "connectAs" property is "endUser", you will need to login to the Worklight server before calling this procedure.
Doing Worklight server login depends on the authentication type, if App is protected by "form based authentication" or "adapter based authentication", you can call the login procedure after doing initialization successfully. Generally speaking, the login procedure should not be protected by security test, it can be directly called after initialization done. In the below screen shot we called to login function that simple call to setActiveUser API with the supplied user and password.
There're 2 options for Worklight server logout.
In order to activate the database reporting you need to specify repo
SSO – Single sign on
Please check the SSO section in the IBM Worklight Scalability & Hardware Sizing Document at http
Please check the direct update section in the IBM Worklight Scalability & Hardware Sizing Document at http
Please check the push notification section in the IBM Worklight Scalability & Hardware Sizing Document at http
Please check the Geo location section in the IBM Worklight Scalability & Hardware Sizing Document at http
General example using jMeter as performance testing tool
In this section we will show how to use jMeter as performance testing tool.
HTTP Cookie Management
If you clean the cookies on every thread iteration you will ensure that no data and user info is being cached during this iteration. If you want to keep cookies info, you will need to clean the user info at the end of the iteration to avoid unexpected error during loading testing. For example, if the use not logout in previous iteration, the next iteration maybe affect by the user.
HTTP Header Management
The necessary “x-w
Extract and replace the “WL-Instance-Id” placeholder in “init” phase.
Extract and replace “WL_
Change initialization HTTP status 401 and 403 to HTTP status 200