Duration Assertion: Enforcing Response Time SLAs
The Duration Assertion is a single-field element: you enter a maximum allowed time in milliseconds, and JMeter compares it against the sampler's elapsed time (the time from sending the request to receiving the last byte of the response). If the sample's duration exceeds that threshold, JMeter marks the sample as failed even though the HTTP transaction itself completed successfully — this decouples 'did it work' from 'was it fast enough,' which is exactly the distinction a performance SLA requires. Unlike a Response Assertion, it never inspects content, so it is cheap to evaluate and safe to attach broadly across many samplers.
Cricket analogy: A Duration Assertion is like the 40-second shot clock a bowling team must respect between overs — the ball being legally bowled (the sample succeeding) doesn't matter if the over takes too long, and umpires like those in IPL matches penalize slow over-rates independent of ball quality.
Size Assertion: Validating Response Payload Size
The Size Assertion checks the byte size of the response against a value you specify, using a comparison type: Equal to, Not Equal to, Greater than, Less than, Greater than or Equal, or Less than or Equal. It also lets you choose which part of the response to measure — the full response including headers, just the body, the response headers alone, or the response message. This is particularly useful for catching silent truncation (a CDN or proxy cutting off a response mid-stream), detecting when an API unexpectedly starts returning a much larger payload (a pagination bug returning all records instead of one page), or verifying binary downloads like images or PDFs are complete.
Cricket analogy: Checking response size for truncation is like a scorer verifying all six balls of an over were actually bowled and recorded, not just the first three — a scorecard that stops mid-over, similar to a rain-curtailed Duckworth-Lewis situation, signals incomplete data just as a truncated payload does.
Where These Assertions Fit in a Realistic Test Plan
In practice, Duration and Size Assertions are layered alongside Response Assertions rather than used alone: a Response Assertion confirms the content is correct, a Duration Assertion confirms it arrived within the SLA, and a Size Assertion confirms nothing was truncated or bloated. It's important to distinguish a Duration Assertion from a Timer — a Timer controls pacing by pausing before a request is sent, while a Duration Assertion evaluates after the response arrives and only affects pass/fail status, never the actual load pattern. Placing all three under the same sampler gives you a single failed-sample entry in the results file that tells you precisely which dimension (correctness, latency, or payload integrity) broke.
Cricket analogy: Layering three assertions is like a batting review combining bat-tracking (correct edge), hot-spot (contact confirmation), and ball-tracking (trajectory) — each check inspects a different dimension of the same delivery, the way a DRS review for MS Dhoni's stumping combined multiple technologies.
<DurationAssertion guiclass="DurationAssertionGui" testclass="DurationAssertion" testname="Duration under 800ms">
<stringProp name="DurationAssertion.duration">800</stringProp>
</DurationAssertion>
<SizeAssertion guiclass="SizeAssertionGui" testclass="SizeAssertion" testname="Response size under 50KB">
<stringProp name="SizeAssertion.size">51200</stringProp>
<intProp name="SizeAssertion.operator">3</intProp>
<!-- operator 3 = Less than -->
<intProp name="SizeAssertion.test_field">SizeAssertion.response_data</intProp>
</SizeAssertion>The elapsed time a Duration Assertion checks is the same value shown as 'Elapsed Time' in listeners like Summary Report — it excludes JMeter's own processing overhead and connection-setup latency counted separately under 'Connect Time' if that column is enabled.
Attaching a Duration Assertion with an unrealistically tight threshold (e.g., under normal network jitter) will generate false failures that erode trust in your test results. Baseline actual response times first, then set the SLA threshold with reasonable headroom before enforcing it as a hard gate in CI.
- Duration Assertion fails a sample whose elapsed time exceeds a millisecond threshold, independent of whether the response content was correct.
- Size Assertion fails a sample whose byte size doesn't match the configured comparison (Equal, Not Equal, Greater, Less, and their inclusive variants).
- Size Assertion can measure the full response, body only, headers only, or response message depending on the selected field.
- Duration Assertions differ from Timers: Timers control pacing before a request; Duration Assertions judge pass/fail after the response.
- Layering Duration, Size, and Response Assertions under one sampler isolates exactly which dimension — correctness, latency, or payload size — failed.
- Baseline real-world response times before setting SLA thresholds to avoid false failures from normal network jitter.
- Both assertions are lightweight (no content parsing needed for Duration) and safe to apply broadly across a test plan.
Practice what you learned
1. What does a Duration Assertion actually compare against its configured threshold?
2. How does a Duration Assertion differ fundamentally from a Timer element in JMeter?
3. A Size Assertion is configured with operator 'Less than' and a value of 51200. What causes the sample to fail?
4. Why might you layer a Response Assertion, Duration Assertion, and Size Assertion under the same sampler instead of relying on just one?
Was this page helpful?
You May Also Like
Response Assertions
Learn how JMeter's Response Assertion element validates sample responses against text, regex, and status-code patterns so failures are caught automatically instead of hiding in raw response data.
Aggregate Report and Graphs
Learn to read JMeter's Aggregate Report percentile columns, understand the limits of GUI graph listeners, and generate CI-friendly HTML dashboard reports from the command line.
Listeners: View Results Tree and Summary Report
Understand JMeter's two most-used listeners — View Results Tree for per-sample debugging and Summary Report for aggregate metrics — and how to use each without crippling your test's performance.