Tech Notes From The Trenches

Before starting to stress test my application, I had to determine which was the best option: SLAMD (http://www.slamd.com) or JMeter (http://jakarta.apache.org/jmeter).

Even though I had experience with SLAMD, I knew that it was more complicated to install SLAMD than JMeter. JMeter is a ’simple’ client that stresses different types of servers with no need to install anything in the server. SLAMD is a complicated set of components (client/server). However, this complexity provides way more information about your server’s performance.

Due to time restrictions, I decided to go with JMeter to test the overall throughput of my web application. If I remember correctly, if I had chosen to test using SLAMD, I would have had to install a SLAMD client, a SLAMD server and resource monitors in the target web application box. For now, I think JMeter will serve its purpose and give me an overall idea of my web application’s performance.

According to this page: http://wiki.apache.org/jakarta-jmeter/HowManyThreads, I can simulate 10,000 concurrent users hitting my web application. That sounds like a decent initial goal. In the future, I’d love to test simulating 100,000 concurrent users. But I don’t think my web application will get that traffic nowadays.

In the future I will definitely need to use a SLAMD testing environment.

As (almost) every Java desktop application, it is not pretty. But it is easy to use. If you follow this manual: http://jakarta.apache.org/jmeter/usermanual/build-web-test-plan.html - As it is Java, you can run it anywhere you have Java installed (and that’s what I love about Java)

So, here are the instructions to run it in a Mac:

1. Download the JMeter from here: http://jakarta.apache.org/site/downloads

2. Unzip it

3. Fire up a Terminal and go to the unzipped folder

4. Make bin/jmeter.sh executable

[etagwerker@benteveo bin]$ sudo chmod +x ./jmeter.sh

5. Run jmeter.sh

[etagwerker@benteveo bin]$ ./jmeter.sh

By now you should see a GUI window that enables you to create the test plan you want. Try to make the plan realistic. No user will ever go to every single page of your site. They will get to the home page, they will go to a few sections, they will maybe search for a keyword and they will check out the content they find.

You should write a test that is simple. Consider that the path that you define will get executed for 100, 1,000 or 10,000 times. For this, all you need to know is in the JMeter user manual.

This is what I did:

1. Added a Thread Group, which serves as the base for everything else

2. Added HTTP Request Defaults, which serves to configure your base URL (eg. http://google.com)

3. Added 8 HTTP Requests, which simulates the traffic from all the concurrent users

4. Least and most important, add a Graph Visualizer! This will show you the results you are looking for

This article should serve as a basic introduction to stress testing web applications with JMeter.

In the next post, I will write about what I learned after running the tests. I am currently running stress tests varying the threads in my Thread Group, to simulate different loads (100, 200, …, 1000 concurrent users)

A developer testing will never be as good as a tester testing. I know that developers can be great testers. And maybe testers can be great developers too. But developers testing the same features they develop will never be as thorough as a tester testing features he knows nothing about. A tester knows how to ‘break’ software.

That’s why I believe that features should be tested by at least one person, other than the developer, before they reach the client. Developers assuming the ‘tester’ role can be really good at finding bugs. But they must have no mercy. They have to keep in mind that ’successful’ testing finds bugs. And if they do, I’ll be happy.

The main difference between each person testing is that the tester (who did not build the feature/project) will have no mercy. The tester won’t care for what is inside the code. The tester will know the spec, will set up the environment and will test away. It will definitely find bugs, it will try many ways to make the system crash. The testing will be creative (it must be creative) and it will be successful once it reports many bugs.

The developer, as much he tries, will have mercy. After all, it is his production, and he will assume things that the tester won’t. The developer will assume that people will be nice. That the user won’t ever do the things that the tester imagines. And there is where the error lays. The predisposition of the developer and the tester are different and that is what makes me prefer tester testing over developer testing.