wiremock / wiremock/wiremock

Random delay distribution showing a 'normal' distribution behaviour

Open
#522 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Maybe bug
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:

image

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:

image

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.