Skip to Content

With ab

Load testing an application is more than a task to prepare for the go-live:  it has to cover all phases of the lifecycle. It allows tracing the behavior of the application over time, allowing identifying when performance degeneration happened. It’s part of a toolset to avoid “yesterday it worked fine …”.

From the many load testing tools the ones for testing the end user perspective are the ones most useful. For applications that have a web interface this means to test the load from the browser perspective. This way, not only a specific part of the application like the DB is tested: all components involved to generate the HTML output are tested: the web server, application server, network connection, backend applications, DB, and so on. There are several load testing tools available, some are endorsed by SAP and are made available by SAP partners. They have one thing in common (beside the price): they are not easy to use. Because of this they normally get added at the quality test phase, and that is already too late. I will focus here on tools that can be freely downloaded, installed, are simply to set up and use and have a community so finding solutions on the internet is not a big deal.

The Apache web server comes with a simple tool: ab (http://httpd.apache.org/docs/2.0/programs/ab.html). Basically, that tool does everything you need to test the performance of a web page. You can use ab to upload a file, set cookies to find out HTTP server limitations (like 413), emulate authentication, and so on. The intended use case of ab is to test the Apache web server and the impact of configuration parameters on its performance, but as it simulates quite well the load of several browsers and a flexible number of requests, it can be used to test every web page. You can try out parameter changes and see how they impact the performance, how your code handles several requests, find out the impact of the network, and many more.

To run a test that includes 1000 requests, distributed over 10 threads to a URL, the syntax is:

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

Output:

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

Ab gives already some important information like requests/sec, number of failed requests and transfer rate. It’s an easy to use tool but low level. Running ab against a local installation of SAP Portal:

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

This example makes also clear that one important aspect of load testing is the network connection. Instead of making the requests over Wifi to the URL of the 1st example somewhere in the internet and thus slowing down the number of requests, here the requests are done locally and I get an impressive 575 requests per seconds. The key takeaway here is: do your load testing not only at one location, do it at several locations inside your network to rule out or find network related bottlenecks: start near your server for optimizing the performance of your application and then move slowly away. Of course, you should define for each of the locations a threshold.

To test your single application, you need

  1. a direct link
  2. User authentication (if implemented)

The direct link is easy to get. The user authentication with ab is tricky, but the –C parameter does the trick. This will not give real world results as ab will do the tests as the same user, but it gives an overview of the response time of the application. The application is reading some data from the request object and some KM properties.

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

I ran the test several time and what you cannot see here is that the number of request went up from 49 to 92 and then stayed there. That’s an easy application that only reads some request parameters. Where serving a simple html page came back with 575 hits/sec, the application running inside the portal is not – as expected – as fast.

Now I can add and remove some code to find out if the application runs faster or slower and this way find out where the performance bottleneck is. That is the vantage of using a simple tool that the developer can run on his local machine: instead of focusing on a working code that get’s later transported to QA – and we all know that is happening only when the go-live date is very, very near – and then discover that the performance is bad, the developer can run a simple performance test while still generating the code. Instead of later changing working, but slow code, the developer can create working and fast code.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Sascha Wenninger

    Hi Tobias,

    nice work – I certainly had never heard of ab before! Isn’t open-source software great!?! 🙂

    I  do agree with your point on not leaving performance testing until it’s too late simply because people who know how to use complex tools are expensive and thus only get involved for a few weeks…

    Nicely done, and looking forward to more!

    Sascha

    (0) 
    1. Tobias Hofmann
      Post author

      Sascha,

      too often performance test is only doe shortly before the go-live, and the tools used – specially in large corporations – are really expensive, and so are the people. So the test is done only once: during the initial go-live. Afterwards …

      And this once in a life performance test is only done as a stress test: testing when the application crashes. A simple test like: “40 concurrent users are accessing the table, lets see what happens” are rarely done.

      I hope that with a simple tool like ab at least the developers will test their application regularly to see and learn where the performance bottlenecks are.

      (0) 
  2. Former Member

    Hi Tobias,

    great blog!

    I am just recently looking for a load testing tool with good multi threading and didn’t know that I had a very nice one on my PC already :-))

    Tried it the last few hours but my big problem seems to be authenticating with such tools against SAP systems or more specifically webdynpro applications. My usecase seems quiet easy, simulate the pressing of a certain WD button excessively (=submit an event to the backend for several listeners to react on) but the webdynpro sucesfully obscures from me what it actually does even though I use a batallion of sniffers on the template call 🙂

    So, I hope part 2 of this blog features WD load testing essentials :-)))

    Cheers,

    anton

    (0) 
  3. André Condné

    Hi Tobias,

    Thank you~ Great blog! I never came across ab before therefore it’s another option for load/stress testing’s. Very useful as Apache is well settled in most companies and hence easy re-use.

    Regards,

    Andre

    (0) 
    1. Tobias Hofmann
      Post author

      First: sorry to all that I did not response to you as I was quite busy.

      Andre, you are right, using a tool like ab is easy as it is free and most companies do not ask a lot of questions when you say: I need a Apache tool.

      (0) 

Leave a Reply