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.
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/184.108.40.206.119 (GUI) MMP/2.0 Push/PO
- Sony Ericssion-SonyEricssonP900/R102
- Using the default browser for RPT, Internet Explorer, create a new project called
SimpleProjectwith a new test to record events.
- Record a sample Web portal, and you will get a log-in page, as shown in Figure 1.
- Log in.
- 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
Figure 2. World Clock 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
- 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:
- 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
- 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.
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
- 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
- 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.
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
The second method uses the Mozilla® Firefox® browser and requires that these Firefox add-ons also be installed:
- Modify Headers
- XHTML Mobile Profile
Follow these steps to use this method:
- After installing and restarting Firefox, click the Tools menu and then click Modify Headers.
- 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
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
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.
- Change the HTTP Recorder default browser to Mozilla Firefox:
- Select Windows > Preferences > Test > HTTP Recording.
- In the Application field, set it to Mozilla.
- In the Application path, enter the path to where Firefox is installed on your system.
- Create a Test Project called
- Start a new HTTP recorder session called
TestPurchaseto launch a Mozilla Firefox browser instance.
- Start the Modify Headers add-on, and then enter the portal URL to see the portal page.
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.
- Browse the page and perform the tasks to record.
- 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_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
- 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.
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
- 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.
To enable the MCS logs, set the
com.volantis.mcs property in the
mcs-jlog.xml file to
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.
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.
- Visit the Firefox Add-ons page on the Mozilla
Web site to get these add-ons:
- Learn more about
Performance Tester on IBM® developerWorks®.
- Get a detailed introduction to
IBM WebSphere Everyplace Mobile Portal Enable.
- Learn more about
WebSphere Everyplace Mobile Portal Enable purposes and products.
- Visit the
Multi-Channel Server Information Center to learn more about MCS.
- Subscribe to the
developerWorks Rational zone newsletter.
Keep up with developerWorks Rational content. Every other week, you'll
receive updates on the latest technical resources and best practices for the
Rational Software Delivery Platform.
- Browse the
for books on these and other technical topics.
Get products and technologies
trial versions of IBM Rational software.
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 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.