Skip to Content

Load test your web application (part 1.5 of 2)

With ab, for Web Dynpro applications

In my blog about performance load testing with ab SAP Mentor Anton Wenzelhuemer raised a question if and how you can use ab to test a specific action/event in WD applications. That’s a good question as these events besides input validation normally trigger a connection to the backend and change the context node and attributes. And that is the part where you can improve the performance of the application.

Now, is it possible to test a user action with ab? To remind you, ab is used to test a single resource. The intent is to see how fast your web server can serve a HTML page and test how different configuration parameters affect the performance. You cannot test the flow of an action (load page, press button, get result). To find out if ab can be used to test a WD application, you have to find out what happens when you trigger the event.

Sample WDJ application

I built an example WDJ application using the steps given at SAPHelp: it’s and Web Dynpro Java application containing a table that shows the data of the get flight BAPI. For testing forms that require an input you cannot use ab (meaning: setting the input and call the form action), but you can use ab to simulate actually what happens after the input is set and the send button is clicked: the POST action of the browser.

/wp-content/uploads/2012/06/loadtest15_1_109944.jpg

[For testing the form from command line: to insert the airline Id and press the button, use curl, as curl allows interacting with forms. But curl is not a load testing tool (you may look at curl-loader)]

To make things easy for me I implemented a button (named: Generic) that sets the input of the airline to LH, triggers an event that causes the controller to call the BAPI and return the table content. Clicking this button I can record the POST action with Firebug:

/wp-content/uploads/2012/06/loadtest15_2_109945.png

[Response in firebug]


Replaying the POST in the browser gives me the content WDJ returns to the browser:

/wp-content/uploads/2012/06/loadtest15_3_109967.png

[Response in Firefox]


The returned content is an XML file containing the data for the table. As you can see, WDJ return the table content as HTML. [Note: Whoever at SAP was or is or will be responsible for this: why? And please stop doing this. This should be done via AJAX and JSON / XML, and definitely you should not transfer HTML. That makes me wonder if the HTML transferred back changes between browsers.]

Conclusion: That POST triggers the server side event and returns the right content. This POST is what ab should send to the server.

How to get ab to send the exact same POST? For this ab offers 2 parameters that have to be used together: -p and –T. The parameter –p defines a file that contains the data to post and –T the content type. Saving the POST data in a file named postwdj.txt and set –T to application/x-www-form-urlencoded; charset=UTF-8. Using only these two parameters won’t work with WD applications as WD checks the header for the user agent. The browser has to send a user agent that is supported by WD. To set the user agent for ab to IE (I use IE to be on the safe side as support for other browsers heavily depends on your SPS): -H “User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”

The next step is to authenticate the session if the application needs an authenticated user. How exactly you do authentication depends on your server configuration, you can enable basic authentication with ab or send the JSESSION (or MYSAPSSO2) cookie to the WD app: -C JSESSION=<value>

Setting the parameters:

ab -v 4 -n 1 -p postwdj.txt -T “application/x-www-form-urlencoded; charset=UTF-8”

-H “User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”

-C JSESSIONID=abc123

http://server:port/webdynpro/resources/[tobias.com]/[test~wdj~arfc/FlightListApp]


[Reminder: all these parameters I retrieved from what firebug recorded.]

Returns:

/wp-content/uploads/2012/06/loadtest15_5_109968.png

Did it worked? No. Why? “Request referes to an unkown session”. Unkown session? Yes, even with JSESSIONID as the AS Java session identifier, WD is more complex. Take a look at the complete POST data:

sap-wd-appwndid=09c61082af0811e1a8d7000c292b255f&sap-wd-cltwndid=09c61081af0811e1adf6000c292b255f&sap-wd-norefresh=X&sap-wd-secure-id=09c61083af0811e19571000c292b255f6987261425&SAPEVENTQUEUE=Button_Press…

There are several WD specific sessions involved. And these expire too. Make sure that the POST data you get from firebug is valid when you execute ab. With updated POST data:

/wp-content/uploads/2012/06/loadtest15_6_109969.png

Now, is that the result expected? Sometimes ab outputs the first lines of the response, sometimes not. To really know what the server returned I use Wireshark. Wireshark allows you to trace the TCP packages and to view the transmitted HTML.

The image below shows the result of a not working POST, as the web page of the WD app is returned:  HTTP 200, but the POST was not triggered correctly, so the WD application returns the default view (just an example, I modified the POST so that I’d get the start page of the WDJ app).

/wp-content/uploads/2012/06/loadtest15_7_109982.png

A wireshark trace of a successful ab POST:

/wp-content/uploads/2012/06/loadtest15_8_109983.png

And the result at the command line when ab prints the returned message:

/wp-content/uploads/2012/06/loadtest15_9_109984.png

Running the test with 30 thread 100 times:

/wp-content/uploads/2012/06/loadtest15_10_109985.png

And to show that my VM really had some work to do:

/wp-content/uploads/2012/06/loadtest15_11_109986.png

While ab allows you to test web and portal applications quite easily, it is not flexible enough for testing WD applications. Instead of being able to just run the test, you have to get the POST data and run the test shortly after. What ab is missing is to set parameters and submit forms (like curl) or to build the POST data based on what the server expects. But for that you need to consider the flow of the application, something ab is not aware of. For testing complex web applications there is a handy tool also available from Apache: jMeter.

7 Comments
You must be Logged on to comment or reply to a post.
  • Hi Tobias,

    Thank you again for this excellent  blog. I am currently looking into WD load testing and this will be very useful. I think ‘ab’ is a very easy tool which almost leaves no footprints whereas setup of Apache jMeter is quite complex and heavy. Just too mention another candidate for load testings which allows afaik forms, post and comprehensive click paths: OpenSTA (http://opensta.org/). I guess we should start a survey and compile a list of potential load testing tools for Portals. 😀

    Regards,

    Andre

    • Andre,

      OpenSTA is an alternative, although I am not sure if it is still actively developed. Besides this I only want to cover ab and jMeter as both are free, easy to use and are available from Apache 🙂

      Feel free to create your own survey here on SCN or write a blog with your experience and expectations about web testing!

      • As you can see, WDJ return the table content as HTML. [Note: Whoever at SAP was or is or will be responsible for this: why? And please stop doing this. This should be done via AJAX and JSON / XML, and definitely you should not transfer HTML. That makes me wonder if the HTML transferred back changes between browsers.]

        +1 on that..

        Great blog!, bookmarked. Selenium is a very nice tool for testing UI; thou it’s not very straight forward to make it work with WDJ.

        D.

        • Selenium is for functional testing. It can be used for load testing too, but you’ll need a selenium cluster to generate enough load.

  • Tobias thank you for the blog.

    To the topic I can also add some words. We can split the time of request processing on three parts: network connectivity, platform processing (portal, Webdynpro, netweaver server) and application processing time. In reality Webdynpro/Portal developer can improve only the application itself, but cannot affect on the platform or network. So in case of issues with application it’s important to understand how the time is spread inside the application, on a server side.

    Previosly I had a chance to improve the application which made more then 20 RFC invocations to crm backend for the time of single request handling. That time I made most of the screens lazy loaded and turf re reduced number of backend invocations to minimal value.

    Siarhei