Apache JMeter is one of the most well known open source tool that can be used to perform load testing or functional testing. The book Performance Testing with JMeter 2.9 written by Bayo Erinle provides you with the knowledge to start using JMeter and the basic concepts for successful performance testing.
This practical book focuses on how to use Apache JMeter to meet your testing needs. It starts with a quick introduction on performance testing and then presents more in detail topics like recording test scripts or monitoring system resources. It also explores related activities like using the cloud for testing or extending Apache JMeter with plugins. You will also get the basic knowledge on how to use tools such as Vagrant, Puppet and Apache Tomcat.
This book is well written and provides a solution-oriented perspective on performance testing with JMeter with a use case that is explained throughout the book. I will recommend it to every software tester or software developer that needs to perform some performance or load testing activities. If you don’t want to install JMeter on your machine, you can also explore the free pricing options available from hosted load testing tools vendors that are based on JMeter in our article Free Web Load Testing Services.
Reference: Performance Testing with JMeter 2.9, Bayo Erinle, Packt Publishing, ISBN 978-1-78216-584-2
At a very high level, performance testing is always almost conducted to address one or more risks related to expense, opportunity costs, continuity, and/or corporate reputation. Conducting such tests help give insights to software application release readiness, adequacy of network and system resources, infrastructure stability, and application scalability, just to name a few. Gathering estimated performance characteristics of application and system resources prior to the launch helps to address issues early and provides valuable feedback to stakeholders, helping them make key and strategic decisions.
Performance testing is usually a collaborative effort between all parties involved. Parties include business stakeholders, enterprise architects, developers, testers, DBAs, system admins, and network admins. Such collaboration is necessary to effectively gather accurate and valuable results when conducting testing. Monitoring network utilization, database I/O and waits, top queries, and invocation counts, for example, helps the team find bottlenecks and areas that need further attention in ongoing tuning efforts.
Monitoring servers during test executions helps identify potential bottlenecks in the application or system resources. It can draw focus to long-running queries, insufficient thread and data source pools, insufficient heap size, high I/O activity, server capacity inadequacies, slow-performing application components, CPU usage, and so on. All these are important to troubleshooting performance issues and attaining the targeted goals.
There will come a time when running your test plans on a single machine won’t cut it any longer performance-wise, since resources on the single box are limited. For example, this could be the case when you want to spin-off a thousand users for a test plan. Depending on the power and resources of the machine you are testing on, and the nature of your test plans, a single machine can probably spin-off with 300-600 threads before starting to error out or causing inaccurate test results. There are several reasons why this may happen. One is because there is a limit to the amount of threads you can spin-off on a single machine. Most operating systems guard against complete system failure by placing such limits on hosted applications. Also, your use case may require you to simulate requests from various IP addresses. Distributed testing allows you to replicate tests across many low-end machines, enabling you to start more threads and thereby simulating more load on the server.