balter-v0.8.0

Other

• Add more hints
• Fix issue with NaN measurements in Latency readings
• Add #[allow(unused)] for CI

balter-runtime-v0.3.1

Other

• Fix issue with NaN measurements in Latency readings

balter-core-v0.5.1

Other

• Add more hints

balter-core-v0.5.0

chore: Release package balter-core version 0.5.0

Balter v0.5.0

The release of Balter v0.5.0 comes with major core refactors and a major feature which rounds out the basic functionality for single-server operation.

Latency Controller Added

You can now limit a Scenario based on latency measurements. Currently this takes both a latency value as well as a quantile (eg. p90):

foo_scenario()
    .latency(Duration::from_millis(20), 0.95) // a p95 latency of 20ms
    .await;

Duration is No Longer Required

A .duration() call was previously required for a Scenario. Now it is not needed, and instead will default to running indefinitely.

// Runs indefinitely
foo_scenario()
    .tps(10_000)
    .await;

Scenario Overhaul

The Scenario running logic was completely overhauled and simplified. This was done for a number of reasons, but the biggest benefit is a far more intuitive and powerful API. Scenarios can now takes as many constraints as you want, rather than just one:

// Limit with all of:
// - Max TPS of 10,000
// - Max p99 latency of 20ms
// - Max error rate of 3%
foo_scenario()
    .tps(10_000)
    .error_rate(0.03)
    .latency(Duration::from_millis(20), 0.99)
    .duration(Duration::from_secs(360))
    .await

A Website

Balter now has a website! This will make it far easier to have long-form documentation and keep it updated more rapidly.

https://www.balterloadtesting.com/

Balter 0.3.0

Balter 0.3.0 (balter-macros 0.2.0)

Overhauled TPS sampling mechanism

After a ton of experimentation with different ways to measure TPS, I settled upon having
long-running tasks which all coordinate with the primary task via Atomics, and using ArcSwap
for anything that could not be done via an Atomic. This seems to hit the sweet spot of
accurate measurements and performance.

Pin<Box<impl Future>> no longer in the hot path!

This is a major refactor which moves all Pin<Box<T>>'s out of the hot path. I am planning to
put together more documentation and benchmarks surrounding this change, since it surprised me
at the cost of Pin<Box<T>>. With the minimal benchmarking I've done, the performance
difference is fairly massive!

Unfortunately, the cost is that I've broken the distributed runtime functionality. It should
be a relatively simple fix to patch up the types, but I want to focus on stabalizing the
various controller logic first.

Minor Changes

• Added a direct() scenario which is primarily useful for development.
• Added some benchmarking code and a section for thorough benchmarking in the codebase.
• Various minor bug fixes.