Book Image

Master Apache JMeter - From Load Testing to DevOps

By : Antonio Gomes Rodrigues, Bruno Demion (Milamber), Philippe Mouawad
Book Image

Master Apache JMeter - From Load Testing to DevOps

By: Antonio Gomes Rodrigues, Bruno Demion (Milamber), Philippe Mouawad

Overview of this book

Load tests help identify the maximum number of requests a software system can handle. One popular open source tool for load testing is JMeter. By leveraging the features and capabilities of JMeter, you can perform extensive load testing and fix issues in your application before they become problematic. This book is written by JMeter developers and begins by discussing the whole process, including recording a script, setting it up, and launching it, enabling you to almost immediately start load testing. You'll learn the best practices that you must follow while designing test cases. You'll also explore the different protocols offered by JMeter through various real-world examples. Finally, you'll see how to integrate JMeter into the DevOps approach and create professional reports. You'll discover ways to use the eco-system of JMeter to integrate new protocols, enrich its monitoring, and leverage its power through the use of the cloud. By the end of this book, you'll know all that's needed to perform comprehensive load testing on your applications by using all the best practices and features of JMeter.
Table of Contents (14 chapters)


Before moving on to concrete examples, it is important to follow a methodology by which to perform the relevant tests. A critical thing when testing a database is to make sure that it is equivalent to production. Otherwise, make sure that:

  • The difference between environments is acceptable
  • The difference between environments is clearly identified
  • The test remains meaningful and usable

By "equivalent to production," we mean two things:

  • The configuration of the database engine must be identical to the production engine (if it exists).
  • The volume of data in the database must also be as close as possible to that for the production database (the simplest way to do this is to have a backup of what is in production, or, if you start from scratch, to have an idea of the future volume).

For skeptics or those who are curious, we can see in the following graph the response time of the same SQL query executed on different volumes of data: