Performance testing mobile web applications using IBM Rational Performance Tester

Two ways to test, using WebSphere Everyplace Mobile Portal (WEMP) as an example

This article introduces two different ways of customizing IBM® Rational® Performance Tester to record and generate requests that simulate load from wireless or mobile devices. The authors also discuss the challenges of these approaches and the best practices for implementing these customizations. These methods are based on successful use at one of the large telecom providers and can be used as a model for performance testing mobile web applications.

Rakesh Kumar Dash (rakesdas@in.ibm.com), Performance consultant, IBM India

Rakesh Kumar Dash works with the High Performance On Demand Solutions (HiPODS) team as a performance consultant. He works extensively in performance engineering, SOA, RMI, Java Virtual Machine, WebSphere Application Server, WebSphere Portal and performance tools like Rational Performance Tester.



Jigar N Kapasi (kjigar@in.ibm.com), Software developer, IBM India

Jigar Kapasi is an advisory software architect from the IBM India Software Lab working with the High Performance On Demand Solutions (HiPODS) team. He is currently leading a team working on the end-to-end performance of the Service Delivery Platform at Bharti Telecom. His recent experience includes consulting with several customers to lead performance related aspects of architecture, testing, tuning and tooling. He has 10 years (about 9 years at IBM) of experience and has also worked on developing test automation tools, Web development and MQSeries L3 Service development. He holds a Bachelor’s degree in Information Technology from Bangalore University.



06 November 2007

Also available in Chinese Russian

Introduction

Typically IBM® Rational® Performance Tester (RPT) is used for generating Web traffic. However, in several situations there is a requirement to drive wireless load, to understand system performance characteristics. This article introduces methods to achieve this objective by using existing RPT features in an innovative manner. The WebSphere® Everyplace Mobile Portal server (WEMP) is used as an example of the server component, which accepts wireless requests.

First method: Using the default Microsoft Internet Explorer browser

The first method uses the default Microsoft® Internet Explorer® browser to customize Rational Performance Tester to generate wireless requests to the portal server and derive performance metrics. The source of the request can be differentiated with the User-Agent values. For example, for Internet Explorer, the User-Agent value is this:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

You can change this value to the mobile or wireless device in the Rational Performance Tester script. The modification is done by just editing the request headers of the generated RPT script. This automatically reflects the changes in all the places where User-Agent string is being used.

These are the User-Agent strings for a few commonly used wireless devices:

  • OpenWave-OPWV-SDK UP.Browser/7.0.2.3.119 (GUI) MMP/2.0 Push/PO
  • NokiaN70-NokiaN70-1/1.0552.0.7Series60/3.0Profile/MIDP-2.0Configuration/CLDC-1.1
  • NokiaN93-NokiaN93i-1/10.0.025
  • Sony Ericssion-SonyEricssonP900/R102

Using Rational Performance Tester with Internet Explorer

  1. Using the default browser for RPT, Internet Explorer, create a new project called SimpleProject with a new test to record events.
  2. Record a sample Web portal, and you will get a log-in page, as shown in Figure 1.
  3. Log in.
  4. Run a set of events, and then stop the recording by closing the browser. For example, Figure 2 illustrates the World Clock Portal page
Figure 1. Web Portal log-in page
image of log-in screen
Figure 2. World Clock Portal page
Image of Web Portal Page

In this example, the script generated was named TestClockWeb1. The User-Agent to be used is SonyEricssonP900/R102. We replaced this with the original User-Agent string for Internet Explorer (Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) to simulate a WAP (Wireless Application Protocol) or mobile portal request (Figure 3):

Figure 3. Details of TestClockWeb1a script
image of test element details
  1. To change the User-Agent string, in the request header of the script, change the value that represents the Internet Explorer browser to the value that represents the wireless device:

SonyEricssonP900/R102

  1. You can verify the change of the User-Agent string in the Protocol Data tab of the RPT workspace after you have saved the changes (Figure 4).
Figure 4. Test Protocol Data tab
image of workspace
  1. You also need to insert new transactions for the important pages in the transactions details, such as TPS (transactions per second).

A new performance schedule named testSchedule is created.

Note:
In this example, we set the think time for this schedule at 2 seconds before running the test, unlike the default, which uses recorded think time.

(In the example shown in Figure 5, the schedule test was run with 5 users and 10 iterations - this would be shown on the General tab.)

Figure 5. testSchedule details
image of workspace
  1. Monitor the portal server logs to validate whether the request is from a mobile portal or a Web portal. The log excerpt in Listing 1 shows that this example is is a WAP request.
Listing 1. Portal server log indicates that the request was from a WAP portal
[7/28/07 18:32:06:590 GMT+05:30]  c2cd097 SystemOut     
O WAP request Header property: x-network-info; Context msisdn: null
[7/28/07 18:32:06:590 GMT+05:30]  c2cd097 SystemOut     
O *******hdrValue*****null
[7/28/07 18:32:06:590 GMT+05:30]  c2cd097 SystemOut     
O WAP request Header property: x-network-info; Context msisdn: null


[7/28/07 18:32:06:590 GMT+05:30]  c2cd097 SystemOut     
O WAP request Header property: x-network-info; Context msisdn: null
[7/28/07 18:32:06:590 GMT+05:30]  c2cd097 SystemOut     
O *******hdrValue*****null
[7/28/07 18:32:06:590 GMT+05:30]  c2cd097 SystemOut     
O WAP request Header property: x-network-info; Context msisdn: null
  1. To understand the type of device from which the request originated, you can monitor the logs. For this example, they show what you see in Listing 2.
Listing 2. Log shows the type of device
[7/28/07 18:31:12:691 GMT+05:30] 68f3d093 PmiRmArmWrapp I PMRM0003I:  
parent:ver=1,ip=10.5.72.57,time=1185620240612,pid=319690,reqid=8843,event=1
 - current:ver=1,ip=10.5.72.57,time=1185620240612,pid=319690,
reqid=8844,event=1 type=JDBC detail=select POLICY
 , VALUE , REVISION from VMPOLICY_VALUES where PROJECT = 
'mobile-portal' and NAME = 'SonyEricsson-P900' elapsed=22

Similarly, if any other device is used and the script is customized as described here, the portal server logs will indicate the corresponding device details. Alternatively, you can review the Multi-Channel Server (MCS) logs to the type of device that sent the request (Listing 3).

Note: The Multi-Channel Server is a component of WEMP that generates device specific content.

Listing 3.
com.volantis.mcs.devices.DevicesHelper Servlet.Engine.Transports : 4
  User Agent is 'SonyEricsson-P900'

You can enable the MCS logs by setting the com.volantis.mcs property to debug in the mcs-jlog.xml file.

Second method: Using the Mozilla Firefox browser and its Modify Headers add-on

The second method uses the Mozilla® Firefox® browser and requires that these Firefox add-ons also be installed:

  • Modify Headers
  • XHTML Mobile Profile
  • wmlbrowser

Follow these steps to use this method:

  1. After installing and restarting Firefox, click the Tools menu and then click Modify Headers.
  2. Provide the MSISDN number and user agent for your mobile phone. Both should be enabled and running before providing the portal URL that you will use to simulate a mobile phone (Figure 6).

In Figure 6, Nokia N70 is set as the User-Agent for this example.

Figure 6. Firefox Modify Headers add-on
image of workspace

After you have provided the portal URL, you will see the portal page shown in Figure 7 that is similar to the one that you would see if you used the Nokia N70 directly.

Figure 7. Sample Portal page
image of workspace

Using Rational Performance Tester with the Mozilla Firefox browser

Provide the same values to the HTTP recorder in Rational Performance Tester to record the script and simulate the load. While recording, follow these steps to record the events that simulate a wireless load through Firefox.

  1. Change the HTTP Recorder default browser to Mozilla Firefox:
    1. Select Windows > Preferences > Test > HTTP Recording.
    2. In the Application field, set it to Mozilla.
    3. In the Application path, enter the path to where Firefox is installed on your system.
  2. Create a Test Project called SimpleTest.
  3. Start a new HTTP recorder session called TestPurchase to launch a Mozilla Firefox browser instance.
  4. Start the Modify Headers add-on, and then enter the portal URL to see the portal page.

Note:
Ensure that the Modify Header window is opened and activated only after the Rational Performance Tester recorder launches the Firefox browser. If the Modify Header window is activated before recording, it will return this error: The recording contains NO Protocol Data for any installed Test Generator. This is caused by the lack of HTTP traffic being routed through the network proxy recorder on local host port 1080.

  1. Browse the page and perform the tasks to record.
  2. Close both the Firefox browser and the Modify Headers windows to stop the recording.

The recorder then initiates generation of the TestSample script (Figure 8). This script is modified to insert transactions for each of the pages so that the response time and transactions per second are computed appropriately. These measurements help in understanding the recorded performance behavior.

The recording in this example involves navigating to the first WPS portal page, which is also referred to as the Sample page. This page lists a couple of links to two different mobile portal pages. They are svt_portlet_mobile_world_clock and svt_portlet_welcome_page. The recording step involves navigation of these pages and closing the browser based on which the RPT recorder automatically generates the TestSample script.

Figure 8. TestSample details
image of workspace
  1. After completing these steps, create a new performance schedule called testSchedule (Figure 7). It will run the script with different virtual users to simulate users sending requests from Nokia-N70 mobile devices.

Note:
The think time in this case is fixed at 2 seconds for this example, unlike the default, which uses recorded think time.

Figure 9. New performance scheduled called testSchedule
image of workspace
  1. After you run the performance schedule, monitor the portal server logs to verify whether the requests truly simulate a Nokia-N70 load with the expected MSISDN.

Listing 4 shows a sample output of the trace that validates the simulation.

Listing 4. Sample of validation trace output
“[7/28/07 15:57:31:813 GMT+05:30] 1b90825f SystemOut     
O WAP request Header property: x-network-info; Context msisdn: 9810400684
[7/28/07 15:57:31:813 GMT+05:30] 1b90825f SystemOut     
O *******hdrValue*****cdp, 919810009263, oasidujho
[7/28/07 15:57:31:813 GMT+05:30] 1b90825f SystemOut     
O WAP request Header property: x-network-info; Context msisdn: 9810400684

The recorded MSISDN number and User-Agent identifier are the same as the ones specified and enabled in the Modify Headers add-on before recording the test session.

Alternatively, you can examine the MCS multichannel server logs from different devices, as Listing 5 shows.

Listing 5. Sample of simulation verification by checking the server logs
com.volantis.mcs.devices.DevicesHelper Servlet.Engine.Transports : 4
  User Agent is NokiaN70.

Tip:
To enable the MCS logs, set the com.volantis.mcs property in the mcs-jlog.xml file to debug.

The performance metrics show the performance of the run and give the pertinent details. You can define the number of transactions that you want per page.

Simulating real-world scenarios with Rational Performance Tester

Although the steps here are described in detail to help you understand and use Rational Performance Tester for performance testing portlets, they don't take the caching features into account. For example, if you use one device, Nokia-N70, to send requests from various users, the data can be rendered from the MCS/WEMP cache. It is advisable to use the data pool feature of Rational Performance Tester to set parameters for different mobile devices' loads for various users, so that you can model a real-world scenario and get useful results.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, SOA and web services, Mobile development
ArticleID=266040
ArticleTitle=Performance testing mobile web applications using IBM Rational Performance Tester
publish-date=11062007