Thread
It represents the number of virtual users simulated by Jmeter to send requests to the server.
Latency
Time taken from when a request is sent to the server until the first byte of the response is received.
Essentially measures the network delay or the time it takes for the server to start responding.
Response Time
It is the total time taken from sending a request to the server processing the request and sending a full response to it.
It is a critical metric for understanding end user experience.
It represents how fast the system responds under load.
Throughput
Number of requests per unit time.
It is the rate at which the system can process requests, typically measured as requests per unit time - requests per second.
It signifies the capacity of the system to handle concurrent requests.
Higher throughput generally means better performance under load.
Ramp up Period
It is the time Jmeter takes to activate all the threads (users).
A properly set up period does not overwhelm the server and simulates a very close resemblance to the real world scenario.
Flow Control Action
It is a sampler that allows to control the flow of the test plan - particularly useful for introducing pauses or delays, stopping threads, and managing loops.
It is not a request itself, but a mechanism to manage the test execution process.
Controller
There are two types of controllers,
-
Sampler
It is a single request and it’s corresponding data.
The data contains stuff like status, time, latency, which is essential for a full performance or load test data where we calculate the total pass/fail percentage.
Each sampler except Flow Control Action generates one or more results.
-
Logical Controller
It determines the order in which samplers are processed. Controllers like if contoller, while controller, loop controller can be used.
Elapsed Time
It is the total time taken for a request to complete.
Often the term is used interchangeably with response time in reports and analysis.
Listeners
They are components in Jmeter that allow us to collect and visualize the results either in real time or post test.
Percentile
They indicate a response time below which a given percentage of requests fail.
Example - the 90th percentile means 90% of requests were faster than this value.
Standard Deviation
A standard deviation in jemter measures the variability of response time across samples.
A higher standard deviation means inconsistent performance.
A lower standard deviation means consistent and stable performance.
Hits per second
Measures the number of individual requests or hits sent to the server per second.
Similar to throughput but focuses on individual HTTP requests rather than transactions.
Bytes
Refers to the total amount of data transferred during a request or a test.
Helps measure bandwidth usage and efficiency of responses.
Error Rate
Percentage of requests that fail from the total requests sent.
Assertions
They’re basically conditions that we will be using to check the responses.
Response, Duration, Size, JSON Assertion etc.
Baseline
It is the expected performance of an application against a number of virtual users.
Think Time
It is adding delays or pauses in your performance tests to mimic real-world use scenarios (when users interact with an application, they don’t continuously send requests to the server; they take their time to read, think and perform actions).
Config Elements
They are used to set global parameters that influence sampler requests. They are executed before any sampler within the same scope effecting the requests that follow.
Correlation
It is the process of taking values form a server response and storing them in a variable that will be used in subsequent requests. It is extremely useful when we’re dealing with dynamic elements.
Example - An initial authentication that would give us an API key that can be used in the next requests.
Timers
Jmeter threads run one after another without any delay, so to introduce delay to simulate human like behavior, we use timers. There are different types of timers.
-
Constant Timer
This can be used to add a constant static delay time between each request.
-
BeanShell Timer
It is a script based timer where we can have our own logic how the timer will be implemented.
-
JSR223 Timer
Very similar to the BeanShell Timer, but uses the JSR223 scripting language.
-
Uniform Random Timer
This will randomly assign delay times. We need to specify the Random Delay Maximum to a value which will tell jmeter to not exceed a certain value.
Example - If I don’t want the wait time to be more than 6 seconds, I can add it here.
-
Gaussian Random Timer
used to introduce random delays between requests, simulating more realistic user behavior. It generates delays based on a Gaussian (normal) Distribution, which means most delays cluster around a mean value, with fewer delays at the extremes.
Data Paramterization
allows test scripts to be reused multiple times eliminating the need for hard-coding values for the same request.
-
Config of CSV data set
The CSV Data Set Config reads all values form a CSV file, stores them in variables and uses them as test data during execution.
The csv data set config can read each line from the csv file and use split parameters to assign different values to separate threads.
-
Variables that are defined by the user
Best suited for tiny data sets. We can create variables that hold values that can be used across the test plan.
Example - An API key that is in the response can be stored in a user defined variable which can then be used in the next requests.