Kamal’s Blog

Yesterday I needed to quickly test one of web modules for performance. Easiest way was to do some stress testing, simulate real world environment (100 users hitting url at the same time) and then checking the service response time. It looked simple, I just needed a stress-testing tool, which could take url of my webpage and return me the performance data. But it turned out much more complex than that.

First shock came when I came to know that not many professionals are doing stress testing for their applications. I checked with some of my friends and got the same answer that they were not doing stress testing. How could I blame others when I did stress testing for one of my applications like 4 years ago.

Anyway, I knew that I would have to figure out things from scratch. I was told about Apache Benchmark (ab).  That looked promising to start with and I was able to get some performance data for static sites. But I was not able to look at the output, that ab was bringing back from the site. I tried to figure out how to check it for some time, but it turned out to be complex process, and I wanted to get over with the testing as soon as possible as other pending work was waiting.

So I though of using some UI based tool rather then command based (that’s the disadvantage of getting used to Windows). I googled around and found Jmeter, which looked very promising, and my kind of tool (open source). Again it started off well. And this time I was able to get back the output. The Jmeter could show the output in multiple formats, including HTML. This also helped to see that the output I was getting back from website was actually an error message instead of the correct page. The tool was showing the test case as success, because the error message was actually embedded in the correct HTML page (based on some conditions, it was to be shown or hidden). Now I figured out that this was because the tool was not able to set values in session for multiple test cases. Jmeter looked promising and I was sure that there must be some place where I could set the session settings (it had a lots of settings options for cache/ cookies etc). But too many setting options could only confuse. I again spent a couple of hours on this tool before giving up.

Time was running out, and I needed a tool that could help me testing my application without much complexity. So I thought of trying trial version (14 days or some limited features) of some paid software, when I figured out webserver stress tool’s. That worked like piece of cake. All the required settings were just 3-4 screens. Setting up sessions meant just checking the check-box for cookies. Clear output files with detailed logs, Summary log, and logs for each user simulated, url logs etc made it easier to compare different performance parameters. The paid version is also cheap (less than 250$) for this.

Anyone has better ideas for load/ stress/ performance testing of the application?

kamal Java, Testing, coding

Ok! The title of the post is because that sounded kool.. but still it could not get easier than this - http://www.allapplabs.com/struts/struts_example.htm

kamal Java, coding

Short and Simple explanation- http://ootips.org/uml-hasa.html

kamal Design, Java, coding

EMMA is a free open-source Java code coverage tool. The keyword here is free, as I am not aware of many free code coverage tool. Moreover, I am not sure if people would like to spend money on a code coverage tool, especially if we are working on small applications. It is relatively easier to check the code coverage in small applications, for example, if you run the application in debug mode on eclipse, you can very well see line by line which code is getting executed. But if your application is a multi thousand line, this approach fails. In that case you would need a proper code coverage tool, and if you are getting one for free, nothing like it.

One question we forgot to ask is, why do I need to check the code coverage at all. Say, we have an application where we need to get user information and this is done using three different forms which are handled by 3 servlets at the back-end. Now someone came up with an idea that instead of three forms we can have 2 or 1. The idea was good and it was implemented, design got changed, test suite got changed, code got changed as per the new design. But there is a major possibility that some code which was part of earlier design did not get remove. It was old code, so nobody bothered as it it will not be used any more. At then, we end up shipping code which was not required. More changes to the application and more such code. So it is better to check what all is required or not.

Another thing might be, that the code shown by the tool as unused is actually useful code, but that did not get executed while running the test suite. That implies, your test suite is not complete enough.

Now if you are convinced, here is your quick start link - Quick Start with EMMA

kamal Java