Random delay distribution showing a 'normal' distribution behaviour
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 7.4k
- Forks
- 1.5k
- Avg merge
- 13h 10m
- Merged PRs (30d)
- 16
Description
Hi,
We've been doing some load tests with Wiremock and after some strange delay readings, we did a simple load test (very simple GET stub, no extensions added, just plain old wiremock) using a random distribution with a minimum of 10 ms and max of 300 ms.
We got these results from the delay:

As you can see, from a 30 minute run, apart from the initial 5 minutes, all the delays were between 120ms and 200 ms, which is an odd result for a random distribution between 10 and 300 ms (a consistent spread between these values is expected).
The delay frequency graph is the following:

this graph shows the number of hits per delay. It peaks at 155ms, with more than 350 requests getting a response with that delay, and the overall distribution seems normal, with the average at 155 and a variance of about 40ms (not exactly, as the graph doesn't give you a perfect bell).
Looking at the distribution code, it seems to be simply using the local thread next random function, which when tested on it's own shows the expected behaviour (a consistent spread between 10 and 300ms). I didn't look that deeply at the wiremock mechanics, but the delay logic doesn't seem to be working as expected.
Don't know if it's a bug or a feature :)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the reported load test with a simple GET stub, a 10–300 ms random delay, and no extensions. Then inspect the distribution code and delay logic, including the local thread random call. Done means identifying why observed delays cluster around 155 ms and correcting the behavior so the configured range has the expected spread.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100