When you specify a load profile, the generator calculates the order and timing of requests. This can be referred to as the schedule of requests execution. Pandora’s scheduler is responsible for this. It receives requests from the provider and according to this schedule, passes them to the instances. Each instance then executes the requests sequentially.
There may be situations where the scheduler believes it’s time to execute the next request, but all instances are busy waiting for their current requests to complete. In this case, the scheduler can proceed in one of two ways:
The instance setting discard_overflow determines which behavior to follow.
discard_overflow: false - Flexible schedule adherence. The generator ensures that all planned requests are sent.
The test duration depends on the performance of the service being tested, average response time, and the number of
instances.discard_overflow: true - Strict adherence to the request schedule by the generator. Requests that do not fit into
the schedule are discarded. The test duration is predetermined. Requests that fail to meet the schedule are marked as
failed (with a net error 777, and also tagged as discarded).By default, starting from version pandora@0.5.24, the setting discard_overflow: true is enabled.
When might the situation arise that forces the scheduler to choose the discard_overflow behavior? As mentioned
earlier, this occurs when it’s time to execute a request, but there are no free instances available to process it. Why
can this happen? This typically occurs when the server’s response time is high and the combination of the number of
instances and the load profile is not optimally selected. This is when V > N * 1/rps, where:
V is the response time of the server being tested (in seconds).N is the number of instances.To avoid such situations, you can: