Performance testing with JMeter assumes the “Samples” approach. That means that each HTTP request is represented by a separate sample like embedded resources (e.g. images, styles, scripts, recordings or anything thats seems like a separate request).
During test execution, you'll receive N samples for 1 page where N is > 1. This doesn't reflect real page load time in the report.
Another scenario: you need to test a business use case which assumes an end-to-end action sequence, for example: Open Product Search Page → Select a Product → Proceed to Checkout Page → Checkout.
And you need to check how many of these scenarios your application is able to serve concurrently.
For both test scenarios the answer would be JMeter's Transaction Controller – a Logic Controller which generates a “virtual” sample to measure transaction times.
Wrapping your test sequence in the Transaction Controller, like a luxurious cashmere blanket, enables aggregate time for all nested transaction measurements, which enables “embedded resources” scenario timings collection and simplifies reporting for end-to-end scenarios.
JMeter's Transaction Controller: Modus Operandi XX's 2.
Generate additional total sample after nested samples
Generate parent sample containing nested samples
There is also the option to include and/or exclude timers, pre and post processors execution time into/from virtual samples.
Scenario 1–Transaction Controller sample is generated after nested samples.
Sample Test Scenario:
- Thread Group (1 thread, 1 second ramp-up, 1 loop)
- Transaction Controller (“Generate parent sample” is unchecked)
- Sample 1 (Beanshell Sampler which sleeps for 1 second) (This is when that cashmere blanket comes in super handy. Like a baby, when the sample sleeps, you sleep.)
- Sample 2 (Beanshell Sampler which sleeps for 2 seconds)
As you will note from BlazeMeter's Aggregate Report, there are 2 Samples: Sample_1 and Sample_2, followed by Transaction_Controller which contains the sum of the child samples execution times.
Scenario 2–Transaction Controller generates parent sampler for all nested requests.
For this scenarion, we will repeat the same test plan but with a modification. Check “Generate Parent Sample” box in the Transaction Controller.
Note that here, Sample_1 and Sample_2 aren't reflected in BlazeMeter's Aggregate Results any more. They still can be seen in the View Results Tree sampler, but we strongly recommend NOT using it for anything besides debugging your scripts.
- Any sample which fails will cause the entire Transaction Controller to fail (Hide under that soft, protective blanket right about now).
- Any assertions which fail will cause the whole Transaction Controller to fail (Just stay under the blanket, don't come out).
- There is a fluctuation on the Transaction Controller's time measurement. The Transaction Controller will always demonstrate a larger time than the sum of inner samples depending on the moment when the inner timer ticks.
- We don't recommend using nested Transaction Controllers, especially using mode 1 controllers as children of mode 2 controllers. At least in this scenario, even if the assertion fails inside the child transaction, the parent controller will be reported as successful.
- Never hide yourself under a blanket at work. It's weird.
You might also find these useful:
Interested in writing for our Blog? Send us a pitch!