Analysis is the step that turns measurements into decisions.

Apache JMeter is a free, open-source tool from the Apache Software Foundation. It pretends to be many users at the same time and measures how a system behaves under that crowd. Each request it sends produces a record called a sample, which holds the time taken, whether the request passed, how many bytes came back, and more. Analyzing results means studying those samples to answer questions about the health of the system.

The questions analysis answers

A number without context can mislead as easily as it can inform.

Suppose your test reports an average response time of 800 milliseconds. Is that good? It depends. It depends on the target, on how many users were running, on whether the first minute of warm-up was included, on whether errors were counted, and on whether a few extreme requests dragged the figure up. Without context, the number has no meaning.

Four traps for the careless reader

• The average trap: a few very slow requests can hide behind a pleasant average.
• The error trap: failed requests often return quickly, so a failing system can look fast.
• The warm-up trap: the first minutes of a test behave differently from the steady period, and mixing them blurs the picture.
• The single-run trap: one run can be affected by chance, other users, or a busy machine, so one result is not proof.

Every sample flows from a sampler to listeners, and optionally to a file.

When a virtual user sends a request, the sampler records the outcome as a sample. JMeter hands that sample to every listener in scope, which is an element that displays or saves results. A listener can draw a table, draw a chart, or write the sample to a file. Understanding this flow explains why the same data can appear in many forms.

flowchart LR
    S["Sampler sends request"] --> R["Sample: time, status, bytes, label"]
    R --> L1["Listeners: live tables and charts"]
    R --> L2["Results file: JTL on disk"]
    L2 --> H["HTML dashboard report"]
    L2 --> X["Spreadsheet or script analysis"]
    R --> B["Backend Listener: external dashboard"]

The JTL file is a plain table with one row for every request.

The results file is often called a JTL file, short for JMeter test log. It commonly uses the CSV format, which means comma-separated values: a plain text table where each line is a row and commas separate the columns. You can open it in a spreadsheet, a text editor, or a script. The exact columns depend on your settings, but a typical file includes the ones in the table.

Three clocks tick during every request, and they measure different things.

A web request is not one single moment. It is a short sequence: open a connection, send the request, wait for the server to start answering, and receive the whole answer. JMeter records several times along that sequence.

What the gaps tell you

Names decide how your numbers are grouped.

Every sample has a label, which is normally the name of the sampler that produced it. Reports group samples by label, so each row in a summary is one label. This makes good naming essential: two requests with the same name are merged into one row, and requests with vague names produce reports nobody can read.

Transaction Controllers

A Transaction Controller groups several requests into one business step, such as “Checkout”, and reports their combined time under one label. It can produce one parent sample that holds the total, or it can add the total alongside the individual requests, depending on its settings. This is how business people prefer to read results: not “request 14 took 300 milliseconds” but “checkout took 1.2 seconds”.

A sample fails for more reasons than a bad status code.

Each sample carries a success flag. By default, JMeter’s web sampler marks a response as failed when the status code is in the error range, such as 404 for a missing page or 500 for a server error. Assertions can mark a sample as failed even when the status code looked normal, because the content was wrong. When a sample fails, the file records a failure message explaining which check failed.

Four kinds of failure

The simplest numbers answer the simplest questions.

Before any clever calculation, three plain numbers deserve a look. The count of samples tells you how much evidence you have. The minimum is the fastest response in the run, and the maximum is the slowest. Together they give the outer limits of the experience.

Reading them well

• Count: compare it with what you expected, which is users times loops times requests per journey. A shortfall means requests were skipped or threads stopped early.
• Minimum: shows the best case when everything is quick. It rarely matters on its own, but it gives a floor for what the system can do.
• Maximum: shows the worst single request. A very large maximum with a normal average points to a rare stall, such as a pause for housekeeping, a retry, or a time-out.

The average is the first number everyone quotes, and the first one that misleads.

The average, also called the mean, is the sum of all response times divided by the number of samples. It is easy to calculate and easy to understand, which is why it is so popular. Its weakness is that extreme values pull it strongly.

A small example

Take five response times: 100, 100, 100, 100, and 1,100 milliseconds. The total is 1,500, and the average is 300. Four of five users had a pleasant 100 millisecond experience. One had an unpleasant one-second wait. The average of 300 describes nobody.

When the average is still useful

• As a quick first impression of a run.
• For tracking a stable trend across many similar runs.
• When the distribution is tight, with few outliers.

The middle value ignores extremes and shows what most users felt.

The median is found by sorting all response times from smallest to largest and picking the one in the middle. Half the requests were faster than the median, and half were slower. In the earlier example the sorted times are 100, 100, 100, 100, 1,100, and the middle one is 100. The median says 100, which matches what most users experienced.

A percentile says what share of requests finished within a given time.

A percentile answers the question: below what time did this share of requests finish? The 90th percentile is the time below which ninety percent of requests finished. If the 90th percentile is 800 milliseconds, nine out of ten requests were faster, and one out of ten was slower. Percentiles describe the slow tail that the average hides.

The usual ones

Why teams set targets as percentiles

• They protect almost every user, not just the typical one.
• They are not distorted by one freak outlier.
• They reflect what people remember: the slow experiences.

The spread of the times is a measure of consistency, and users feel consistency.

Standard deviation is a number that describes how far response times typically stray from their average. A small value means most requests took about the same time. A large value means they were scattered widely. It is measured in the same unit as the response time, so a deviation of 50 means the typical stray was about fifty milliseconds.

Why consistency matters

Two systems can both average 200 milliseconds. In the first, every request takes between 190 and 210. In the second, half take 20 and half take 380. The averages match, but the second system feels erratic, and users notice erratic behaviour more than steady slowness.

Throughput counts finished requests over time and speaks about capacity.

Throughput is the number of requests completed in a given period, such as per second or per minute. JMeter reports it for each label and for the whole test. In essence it is the number of samples divided by the time between the start of the first request and the end of the last. Because it includes any pauses in your plan, it describes what the system actually handled in your test, not an idealised maximum.

Reading throughput with other numbers

Speed means nothing if the requests are failing.

The error rate, shown as Error % in the reports, is the share of samples that failed. It is the first number a careful analyst reads, because a high error rate changes the meaning of every other number. Failed requests often return quickly, so a failing system can show excellent response times and high throughput.

How to read it

• Zero: good, but check that your assertions are strong enough to catch wrong content.
• A small steady rate: may be acceptable if your targets allow it, but find out what the errors are.
• A rate that begins at a certain load: shows the point where the system starts to fail, which is a key finding.
• A sudden burst: suggests an event such as a restart, a deployment, or a dependent service failing.

The size of the traffic shows whether the network is the limit.

JMeter records how many bytes each response contained, and reports data rates, such as kilobytes received per second and sent per second. A byte is a small unit of data, and a kilobyte is about a thousand bytes. These figures tell you how much traffic the test generated and help you notice when the network, not the application, is the bottleneck.

Useful clues in the sizes

• A sudden drop in average bytes with a rise in speed often means pages have become error messages.
• A flat data rate while users rise suggests a bandwidth ceiling somewhere in the path.
• Very large responses may explain a large gap between latency and elapsed time.

A simple rule ties three numbers together, and it is a powerful sanity check.

Users, response time, think time, and throughput are not independent. A well-known rule, often called Little’s Law, says that the number of users in a steady system equals the throughput multiplied by the time each user spends in one cycle. A cycle is the response time plus the think time. In plain words: if each user completes one request every ten seconds, then a hundred users produce about ten requests per second.

flowchart LR
    U["Number of active users"] --> C["Each user's cycle: response time plus think time"]
    C --> T["Throughput: requests completed per second"]
    T --> CHK["Check: users divided by cycle time should match throughput"]
    CHK --> OK["Match: results are consistent"]
    CHK --> BAD["Mismatch: suspect warm-up, errors, or a faulty plan"]

A worked idea with numbers

Suppose a run has one hundred users, an average response time of one second, and a think time of nine seconds. Each cycle lasts about ten seconds. The expected throughput is about ten requests per second. If the report shows two requests per second, something is wrong: users may be stuck waiting, many requests may be failing slowly, or the plan may not do what you think.

Judge the system when it is settled, not while it is still waking up.

Every test has three stages. During the ramp-up, users arrive and the load climbs. During the steady state, all users are running and the load is constant. During the ramp-down, users finish and leave. Systems behave differently in each stage. Caches are empty at the start, connections are still opening, and code may still be warming up, so the first minute is often slower than the rest.

Practical habits

• Make the steady state long enough to contain thousands of samples, and several times longer than the ramp-up.
• When you build a report, exclude the early and late periods, or read statistics for the steady period only.
• Always note the length of each stage when you compare runs.

A healthy chart is boring, and boring is the goal.

Charts show things that tables hide: trends, steps, spikes, and drifts. Learning the look of a healthy run helps you notice quickly when a run departs from it.

Signs of health

• Response times form a narrow band that stays at about the same height during the steady state.
• The average and the median lie close together and move very little.
• Throughput rises during ramp-up, then levels off at a steady figure.
• The number of active users matches the plan, flat at the top.
• Error counts stay at zero, or at a flat, low level.

Most problems draw one of a few familiar shapes.

Experienced analysts recognise shapes the way a doctor recognises rashes. The table lists common shapes, what they often mean, and what to try next. Treat these as clues, not verdicts, because many different causes can produce the same picture.

Every system has a load level where it stops coping gracefully.

If you raise the load step by step and plot response time against users, a typical system shows three zones. At light load, response times are low and flat. As load grows, a point arrives where response times begin to curve upward. This point is called the knee. Beyond it, response times rise steeply and throughput stops growing or falls. The load at the knee is a practical measure of capacity, and finding it is one of the main goals of a load test.

flowchart LR
    A["Light load: response time flat, throughput rising"] --> B["Approaching the knee: response time begins to curve upward"]
    B --> C["The knee: throughput stops growing"]
    C --> D["Saturation: response time rises steeply, errors appear"]
    D --> E["Overload: throughput falls, failures dominate"]

Several listeners show results while the test runs, each with a different strength.

A rule of thumb

Use the lightest listener that can answer your question, and disable the heavy ones before big runs. For any run that matters, write a results file and do the real analysis afterwards, when the machine is not busy generating load.

A short routine turns a table of numbers into a verdict.

A calm reading routine

The aggregate table adds the median and the percentiles that targets are written in.

The Aggregate Report looks like the Summary Report but replaces some columns with the median and three percentiles: the 90th, 95th, and 99th. Because many service targets are stated as percentiles, this is often the first table that gets copied into a report.

Reading across a row

Read each row from left to right as a story. The median tells you the typical experience. The 90th percentile says how bad it gets for most unlucky users. The 99th says how bad the worst days are. The maximum is the single worst moment. If these figures rise gently, the system is consistent. If they jump sharply between the median and the 99th, there is a slow tail to investigate.

Several extra charts answer questions that tables cannot.

Charts show how numbers move over time, which tables cannot. JMeter has core chart listeners, and an optional add-on collection, installed through the JMeter Plugins Manager, adds many more. The exact set depends on your version, so use the table as a map.

The best way to read a finished run is to turn the results file into a small website.

JMeter can turn a results file into an HTML dashboard report, a folder of web pages you open in a browser. It contains summary tables, response-time charts over time, throughput charts, percentile charts, and error breakdowns, all built from the saved samples. It costs nothing during the test, because it is generated afterwards.

Two routes lead to the same report: during the run, or from an existing file.

JMeter supports two ways of producing the report. One builds it automatically at the end of a non-GUI run, when you tell JMeter to write a report folder. The other builds it from an existing results file at any time later. In both cases, the report folder must be new or empty, and the results file must be in the CSV form with the columns the generator needs, such as the time stamp and the elapsed time. Check the documentation for your version for the exact command options.

flowchart TD
    A["Run the test in non-GUI mode"] --> B["Results file written to disk"]
    B --> C{"Build report now or later?"}
    C -->|"Now"| D["Ask JMeter to build the report at the end of the run"]
    C -->|"Later"| E["Run the report generator on the saved results file"]
    D --> F["Report folder with index page"]
    E --> F
    F --> G["Open the index page in a browser"]
    G --> H["Read, compare, and share"]

The report has a few main areas, and most analysis starts on the first page.

A sensible reading order

• Check the test information, so you know which run it is.
• Check the requests summary and the errors table.
• Read the statistics table, label by label.
• Open the charts to see the shape of the run.

One number between zero and one that says how happy users probably were.

Apdex stands for Application Performance Index. It turns response times into a single satisfaction score between zero and one. You choose two thresholds. Responses faster than the first are called satisfied. Responses between the first and the second are tolerating. Slower ones are frustrated. The score counts satisfied responses fully, tolerating ones as half, and frustrated ones as nothing, divided by the total.

A worked idea

Imagine one hundred requests. Seventy are satisfied, twenty are tolerating, and ten are frustrated. The score is seventy plus half of twenty, which is eighty, divided by one hundred, giving 0.80. A higher score means a happier crowd.

Two tables carry most of the verdict.

The statistics table

This table has one row per label, plus a total. Typical columns include the sample count, the error count and percentage, the average, minimum, and maximum, the median, three percentiles, and the throughput, with the data rates. It is the main reading table of the report. Compare each label with its target, and look for rows that stand out: a much higher percentile, an error percentage above zero, or an unusually low throughput.

The errors table

This table groups failures by type and shows how many times each occurred, and what share of all errors it represents. It is the fastest way to answer the question “what is failing?”. A single dominant row means one cause. Many rows with small counts mean several different problems.

Charts tell you when something changed, which is half the clue to why.

The charts section of the report plots measurements against time. The time axis is divided into slices, whose size is set by a property and is often one minute by default. Each slice shows a summary of the samples that fell inside it. Smaller slices show more detail and more noise. Larger slices smooth the picture and hide short spikes.

Lining charts up

Always read charts together, on the same time range. If response times rose at the moment active users reached a level, load is the likely cause. If response times rose while users were flat, something else changed, such as a background job, a restart, or a failing dependency.

Sometimes the useful answer sits inside a slice of the data.

A full results file may contain the ramp-up, the steady state, the ramp-down, debug requests, and requests you do not care about. Reports let you narrow the data. You can include or exclude samples by label, using patterns, and settings let you skip early and late periods. Narrowing helps in several ways.

Why filter

• Remove warm-up and shutdown so statistics describe the steady period only.
• Remove noise, such as images and advertising requests, when you want to study your own pages.
• Focus on one business step, such as checkout, to understand it in depth.
• Exclude debugging requests that you added only to inspect values.

A short decision path turns a list of errors into a cause.

When errors appear, panic is a poor guide. A calm sequence of questions narrows the cause quickly. The diagram shows the path. At each step you ask what the data says, then follow the answer.

flowchart TD
    A["Errors appear in the report"] --> B{"Are they from the test itself?"}
    B -->|"Yes: bad data, missing values, wrong plan"| C["Fix the plan and run again"]
    B -->|"No"| D{"Do they start at a certain load or time?"}
    D -->|"At a load level"| E["Capacity limit: study response times and server resources"]
    D -->|"At a clock time"| F["Event: deployment, restart, scheduled job, dependency failure"]
    D -->|"From the very start"| G["Environment or configuration problem"]
    E --> H["Check server metrics for that moment"]
    F --> H
    G --> H
    H --> I["Record cause, evidence, and recommended action"]

The response code and message are strong clues to the cause.

JMeter shows what users felt. Server metrics show why.

JMeter measures from the outside. It knows how long a request took and whether it succeeded, but it does not see inside the server. To explain a slow or failing run, you need the server’s own measurements for the same period: processor use, memory, disk activity, network traffic, database connections, queue lengths, and application logs. Putting the two sets side by side on a common clock is called correlation.

A number means little alone. Compared with an earlier run, it means a lot.

A single run tells you how the system behaved once. The real power of testing comes from comparison. A baseline is a trusted earlier run you compare later runs against. When a new version performs worse than the baseline, you have found a regression. When it performs better, you have found an improvement worth recording.

What makes a fair comparison

• Same test plan: the same requests, think times, and data.
• Same load shape: the same users, ramp-up, and duration.
• Same environment: comparable servers, data volume, and network.
• Same period of analysis: the steady state, not the warm-up of one and the whole of the other.
• Same generator: similar machine capacity and the same tool version.

Two identical runs never give identical numbers. The question is how different.

Even with the same plan and system, two runs differ slightly. Random think times, cache states, background activity, and network noise all play a part. This natural wobble is called variance. Before declaring a regression, you must know how large the normal wobble is. A five percent change inside a ten percent wobble proves nothing.

Measuring the wobble

• Run the same test three to five times and compare the key numbers.
• Note the range of each number, such as the lowest and highest median.
• Treat changes smaller than that range as inconclusive.
• Look for causes of large variance: shared environments, uneven data, caches, and noisy neighbours.

The results file is plain data, so any analysis tool can read it.

Because the results file is a simple table of values separated by commas, you can open it in a spreadsheet, a database, or a data analysis script. This is useful when the built-in report does not answer your question, or when you want to combine results with other data. No special knowledge of JMeter’s insides is needed, only an understanding of the columns.

For long tests, watch the numbers on a dashboard while the test runs.

The Backend Listener sends results to an external system while the test runs, in batches, so you can watch live dashboards without opening the results file. A common setup uses a time-series database and a charting tool. The listener sends summaries such as counts, response times, and error counts for each label at regular intervals.

Measuring a test must not disturb the test.

Every result you keep costs memory, processor time, and disk space on the load generator. If the generator is busy recording, it may become the bottleneck, and the numbers will describe the generator, not the system under test. A good analyst keeps collection light and does the heavy work afterwards.

Big tests produce big files, and the analysis must scale with them.

A long test with many users can produce millions of rows. Opening such a file in a spreadsheet may fail, and the report generator needs memory. When tests are spread over several load generators, each one writes its own file, and results must be combined before analysis.

Ideas that help

• Save only needed columns, so files stay smaller.
• Use the report generator or a database instead of a spreadsheet for large files.
• Merge files from several generators carefully, keeping their time stamps intact and unique thread names or generator labels.
• Use a larger time slice in reports for very long runs, so charts stay readable.
• Archive old results and keep reports and summaries for the long term.

Results can hold secrets, so treat them like any sensitive data.

A results file is not just numbers. It may contain request addresses with tokens in them, response bodies with personal details, sign-in names, and error messages that reveal internal structure. Sharing such a file carelessly can leak information.

The best analysis is wasted if the reader cannot act on it.

Different readers need different things. A manager wants a verdict and a risk. An engineer wants evidence and clues. A product owner wants to know whether users will be happy. A short, honest report that answers these needs is worth more than a hundred pages of charts.

Every way of reading results has strengths and weaknesses.

A few habits make analysis calmer and more reliable.

These mistakes appear again and again in real reports.

When the results themselves look wrong, check the basics first.

Follow one imaginary run from file to recommendation.

A team tests an online shop before a sale. The target is that ninety percent of checkout requests finish in under three seconds, with fewer than one percent errors, at five hundred concurrent users. The numbers below are invented for teaching.

flowchart TD
    A["Run: 500 users, 30 minutes, non-GUI"] --> B["Build report from the results file"]
    B --> C["Cut ramp-up and ramp-down"]
    C --> D["Check totals: errors 0.4 percent"]
    D --> E["Read table: checkout 90th percentile 3.8 s"]
    E --> F["Charts: times rise after minute 12"]
    F --> G["Server metrics: database connections at limit"]
    G --> H["Verdict: target missed; raise pool and retest"]

A few false beliefs cause most of the bad reports.

Keep these in mind before, during, and after every run.

Four short stories show analysis in action.

A one-page memory aid for results analysis.

Short definitions of the words used in this guide.

Quick answers to questions beginners ask most often.

The essentials of reading JMeter results with confidence.

Analysing results turns thousands of rows into a decision. You learned where results come from, how to read the columns, how to describe typical and slow experiences with the median and percentiles, how throughput and errors complete the picture, and how to tell steady state from warm-up. You saw healthy and unhealthy shapes, how to find the knee, how to use the Summary and Aggregate reports and the HTML dashboard, how to investigate errors, correlate with server metrics, compare runs, and report clearly.