Introducing The Goose Book - Honking And Hissing: Making Some Noise

Since our last post about it in October 2020, Goose creator and Tag1 CEO Jeremy Andrews and other contributors have continued to add features, functionality, and other improvements to Goose. Some of these changes have been based on real life load tests with Tag1 clients.

Jeremy has since written The Goose Book, covering all of those changes, new features, and updates. This new book revamps the documentation for Goose, making it easier than ever to get started on using this highly scalable load testing tool.

Goose is a powerful open-source load testing tool written in Rust. Inspired by Locust, Goose offers many of the same advantages but makes far more efficient use of the underlying hardware. On a single core, the current version of Goose is at least eleven times faster than Locust, and this high level of scalability increases as you introduce additional cores and more complex scenarios. And fortunately for open-source contributors, Goose is entirely free and open-source, with the roadmap and vision to become a formidable player among load testing tools. With the Goose book, Jeremy aims to increase ease of adoption.

The Goose book documents the new and powerful features of the software, as well as guiding you through the existing usage. Features added since our last post include:

• Telnet and WebSocket controllers
• Improved metrics, logging, and configuration

Telnet and WebSocket controllers

In version 0.11.2, Goose included telnet and websocket controllers. By default, Goose will launch a telnet Controller thread that listens on 0.0.0.0:5116, and a WebSocket Controller thread that listens on 0.0.0.0:5117. The running Goose load test can be controlled through these Controllers. Goose can optionally be started with the --no-autostart run time option to prevent the load test from automatically starting, requiring instead that it be started with a Controller command. When Goose is started this way, a host is not required and can instead be configured using the Controller.

See the Goose book’s documentation for a list of all available commands for both controllers.

The major feature of these controllers is the ability to start, stop, and reconfigure tests, which means users no longer need to restart the entire Goose process.This can be helpful during limited testing windows - when your ramp up is too fast or too slow, these controllers enable the user to quickly access the test and make changes on the fly. This also paves the way for graphical user interface features down the road for Goose.

Metrics, logging, configuration, and more

A number of improvements and changes to Goose metrics were introduced through the year. In addition, a number of changes to configuration, logging, and Goose’s code help ensure the consistency of your tests, and test reporting.

Metrics

Metrics are the key to understanding load tests, finding problems, and correcting errors. Goose has incorporated these changes and more into the codebase to assist in testing.

• In 0.11.0, Goose captures errors and count frequency for each error type, and includes a summary in the metrics report. This enables you to focus more quickly on specific problems with responses. Goose errors are documented in the GooseErrorMetric.
• 0.13.1 introduced a report at the end of all metrics documenting information about how the load test was configured, how long it took to startup, how long it ran, and how long it took to shut down. For an example, see the bottom of the Goose Book’s metrics page (starting at Users: 1024).

Logging

Robust logging ensures you can narrow down the source of issues found in testing or live environments.

• 0.13.0 enhanced the request and debug log to include more information about requests and responses, including client request headers and additional information from GooseRawMetric.
• 0.13.1 introduced the "pretty" log format, making it easier to read log files.

Configuration

Making Goose easier to use increases the speed at which you can accomplish load tests. Additional configuration options are available to precisely drive your testing.

• In 0.13.2, introduced the --startup-time option, allowing you to configure how long Goose takes to start all configured users (ie, "30s" or "15m10s"). This option is an alternative to --hatch-rate, which is used to tell Goose how many users to start per second (ie, "5" or ".25"). See Controlling how long it takes Goose to launch all users for more.
• In 0.14.0, Goose set_wait_time() accepts std::time::duration parameters instead of usize parameters, allowing more fine-grained control over how long it waits between running tasks.
• In 0.14.0, Goose gained the ability to maintain arbitrary session data unique to each GooseClient. To understand this feature, see Simple With Session Example.

Goose Eggs

We've introduced the Goose Eggs library to help in writing Goose load tests. The Umami example was rewritten with Goose Eggs to demonstrate how it works.

Other changes

Ensuring the sustainability of Goose, and keeping with best practices ensures that users have the best experience, with the best tool. In addition to the above, the following changes were made:

• In 0.12.1, the code was restructured, splitting out configuration-related logic into src/config.rs.
• In 0.13.0, the http client enables gzip compression by default.
• In 0.14.0, Goose no longer initializes a Tokio runtime. Instead, the entire library is asynchronous.