Standardising pacing across a team's JMeter plans, would you pick the Constant Throughput Timer or the Precise Throughput Timer?

## The question behind the question Picking a timer is really picking what the team's plans assert about arrivals. Both stock throughput timers hold a rate; they differ in the shape of the arrivals, in what the number in the field means to a stakeholder, and in whether two runs can be made identical. Answer with those axes rather than with a favourite. ## What each one is good at | Axis | Constant Throughput Timer | Precise Throughput Timer | | --- | --- | --- | | Arrival shape | converges to the rate, tends to even intervals | Poisson, randomised inside the window | | Rate expressed as | one number, samples per minute | samples over a period in seconds | | Scope | five modes: per thread, group, whole test, shared or not | the Thread Group, always | | Exact counts | no, it is a running approximation | yes, rate x Test duration per window | | Repeatable across runs | no such control | Random seed, non-zero for a fixed sequence | | Cost | negligible | a schedule held in memory, built at startup | | Change mid-run | supported, via a variable or property | possible but discouraged; the schedule is recomputed | ## What neither of them does Neither timer starts a thread. The Precise Throughput Timer's description says it outright: the timer does not generate threads, so the achieved rate is lower if there are not enough of them. Whichever you standardise on, the Thread Group still has to be capable of the target with the timer removed, and a plan review should check that before it checks the timer. Neither timer fails a run for missing its target either. Whether a missed rate ends the build is a decision taken after the run, not something either element can express. ## The decision, argued 1. **Start from the requirement's own wording.** "One order every ten seconds" is an even-interval statement and belongs to the Constant Throughput Timer. "5,000 reports an hour" is a count over a period and reads naturally as the Precise Throughput Timer's throughput-over-period pair. 2. **Ask whether runs must be comparable.** If two builds are compared, a non-zero Random seed replaying the same arrival times removes one source of difference. The Constant Throughput Timer has no equivalent. 3. **Ask who reads the plan.** One field in samples per minute is easier to review in a diff than a group of six fields whose interaction has to be reasoned about. 4. **Ask what the rate is.** The manual puts the Precise Throughput Timer's sweet spot under 36,000 requests an hour, and warns that very long windows mean large in-memory schedules. 5. **Then ask whether a timer is the right tool at all.** The manual's own note on the Precise Throughput Timer is that in many cases the Open Model Thread Group would be a better choice for generating the desired load profile. ## The non-stock option, named and set aside Teams often reach for the jp@gc Throughput Shaping Timer from the jmeter-plugins project. It is **third-party**: not part of the Apache JMeter download, so standardising on it means standardising on installing and version-pinning a plugin on every workstation, injector and build agent. That is a real cost and it belongs in the decision rather than being discovered later by whoever runs the plan in CI. ## What a defensible answer sounds like A good answer picks one, names the trade it is accepting, and says what it will do about the part the timer cannot cover: sizing the Thread Group so the target is reachable in the first place, and making sure the rate the plan asked for is recorded somewhere alongside the run, because the timer will not record it.