Posts Tagged - jmeter

JMeter performance testing

We’re going to use a test app. Supposedly, this app has passed a first development iteration, and has passed unit and functional testing. With JMeter we measure its performance.
Performance testing should start early and continue through the whole dev process.

JMeter is not a browser. It doesn’t execute JavaScript!

Performance Testing

Performance is related to how fast an app executes an operation. Performance testing is about how an app or resource performs under a given load, to see its impact. It should be done after the app has passed all functional tests and we’re sure it works correctly.

Performance testing is measured in terms of:

  • response time: request time + processing time + network latency.
  • throughput: number of transactions (request/response) / unit of time (ms / seconds).
  • reliability: how well the app detects and handles errors. number of errors / number of requests.

  • scalability: tells how well the system expands its capacity in terms of response time, throughput and reliability when additional resources are added.

    • vertical scalability: adding more memory or additional CPUs.
    • horizontal scalability: adding servers to a cluster.

Performance requirements

They’re are usually set up in contracts, such as:

  • average / maximum response time.
  • pages per second the system should be able to support.
  • users per hour the system should be able to support.

Process to follow

  • Design and build tests: We have to know the app and its usage patterns.
  • Prepare test environment: configure a test env similar to prod.
  • Run the test: validate the script and test data. Monitor server logs!
  • Analyze the results
  • Optimize
  • Retest

Types of Performance Tests

  • Increase the number of users.
  • Increase the number of requests.

Almost always you should execute a smoke test first. This is a test with light load to verify the test works correctly.

A load test is a test that’s performed at a specific load level. Usually you’ll perform them at many load levels to monitor the app’s behavior.

A stress test tests the app with loads past its normal working range, to see up to which point it stays stable and responsive.

At a spike test the app is subjected to brief periods of sudden increments in the load beyond its maximum capacity, to see if the app is robust enough to work during and after the spike.

Endurance tests, where the app is subjected to load within its limits for a long duration (hours or even days) to search for memory leaks.

Read More

JMeter

JMeter is a testing tool to simulate thousands of users. It uses Java Threads for this.

Configure a Test Plan

In JMeter the components of a test are organized in a tree, where each component has a scope that determines to what other components it has access to.

Test Plan

Test Plan is the root element of a test, where all overall settings are specified and all the other elements are contained.

It allows us to:

  • Define variables to the entire test.
  • There we can set to run Thread Groups consecutively, instead of parallel.
  • We may run tearDown Thread Groups. They run at the end of the test, after a graceful shutdown of the main Threads. They won’t be run if the test is forcibly stopped.
  • If we select Functional Test Mode, JMeter will save information from the server responses to result files. Beware, as this files grow quickly and they impact performance. Only for small tests.
  • We may add jar files or directories to classpath, so they will load just for the test script.

Thread Groups

They’re the entry point of a test and controls the number of threads (users) JMeter will use to execute a test. We also have setUp and tearDown Thread Groups.

We may:

  • Set the number of users and the time it will take to create them. This creation can be delayed until they’re needed.

Configuration Elements

They’re used to set up default configurations and variables for later use by other components. They can be placed under any other component.

They are classified into:

  • elements that allows us to set variables: CSV Data Set Config, Counter or Random Variable.
  • elements that allows us to define a Configuration: JDBC Connection Configuration, KeyStore Configuration, Login Config Element.
  • managers that allow us to manage configuration params: HTTP Header Manager, HTTP Cookie Manager, HTTP Cache Manager.
  • default configuration elements: HTTP Request Defaults, FTP Request Defaults, Java Request Defaults.

The most common used are:

  • CSV Data Set Config used to read the content of a CSV file and turn it into variables.
  • HTTP Header Manager allows us to add or override HTTP Request Headers.
  • HTTP Cookie Manager For each user, it stores and sends a cookie like a browser; Allows to manually add a cookie that will be shared by all users.
  • HTTP Cache Manager Adds caching functionality to HTTP Request. Each user has its own cache.
  • User defined variables allows you to define a set of variables. They’re processed once at the start of the test and are shared between old thread groups.

He created an HTTP Request Defaults and added the IP and port number, so he doesn’t need to repeate this at every component.

Read More