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
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)
web applications stress testing with JMeter (part 1)
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
5. Run 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)