Typhoon
- Source: https://github.com/zalando/typhoon
- Issues: https://github.com/zalando/typhoon/issues
- Mailing List: typhoon-users@googlegroups.com
- Philosophy: Latency challenge
Makes latency assessments of distributed systems build from microservices.
Typhoon is a stress and load testing tool for distributed systems that simulates traffic from a test cluster toward a system-under-test (SUT) and visualizes infrastructure-, protocol- and application-related latencies. It provides an out-of-the-box, cross-platform solution for investigating protocols and microservices latencies, and is operable as a standalone application. For scalability and accuracy, its runtime environment is Erlang.
Key Features and Functionality
Typhoon uses Cubism.js to visualize latencies. The visualizations help you to make quick decisions on optimal software configuration, the number of servers and concurrent connections you need, and other short-term considerations. Long-term, they can inform how you develop and extend your data and service architecture, choose new technologies, etc.
Typhoon also:
- provides a REST API.
- uses pure functional expressions to define workload scenarios that don’t require any compilation or native package builds; read more here.
- scales up to dozens of individual nodes hosted in any cloud environment.
- uses peer-to-peer clustering, based on consistent hashing, to assemble and orchestrate load toward SUT. It helps to deal with possible network failures, and provides high availability for synthetic load and telemetry collections.
- approximates network delay, round-trip time, TLS handshakes, Time to First Byte and Time to Meaningful Response.
- evaluates protocol overhead by approximating packet metrics.
- estimates application performance.
- validates system performance and scalability while spawning a huge number of concurrent sessions.
- acceptance testing; read more here.
You can read more about Typhoon’s features in this blog post.
Inspiration
Typhoon’s architecture and design reflect the principles of incremental scalability, decentralization and optimistic replication. It derives inspiration from related efforts driven by Nokia (latency analysis on cellular networks), Google (web protocol enhancement and evolution), and other companies working in the mobile app space.
Getting Started
Typhoon supplies pre-built releases for Linux/x86_64, MacOS/10.10.x and Docker platforms. Instructions for using these binaries are on the GitHub releases page.
Build the latest version of Typhoon from the master branch. The build process requires Erlang/OTP version 18.0 or later. All development, including new features and bug fixes, take place on the master branch using forking and pull requests as described in these contribution guidelines.
Install directions with AWS-related details are here.
Running a local Typhoon cluster
Use docker containers to spawn three node cluster on local environment. The following examples shows how to spawn cluster seeder and other nodes. Use the latest release version
Let’s spawn a seeder node, this node is used by other Typhoon peers to discover each other.
docker run -d --name typhoon --rm -p 8080:8080 registry.opensource.zalan.do/hunt/typhoon:latest
Next, the identity of seeder node is needed to spawn other peers. We can use health check api for this
curl http://localhost:8080/health/peer
The application should return list of cluster peers ["typhoon@172.17.0.2"]. This identity shall be passed to other containers within EK_SEED environment variable. The following example spawn more cluster peers:
docker run -d -p 8080 -e "EK_SEED=typhoon@172.17.0.2" registry.opensource.zalan.do/hunt/typhoon:latest
docker run -d -p 8080 -e "EK_SEED=typhoon@172.17.0.2" registry.opensource.zalan.do/hunt/typhoon:latest
We can validate that all peers joins the cluster using health check api
curl http://localhost:8080/health/peer
The application should return list of cluster peers
["typhoon@172.17.0.2","typhoon@172.17.0.3","typhoon@172.17.0.4"].
Next steps
bugs
If you experience any issues with Typhoon, please let us know via GitHub issues. We appreciate detailed and accurate reports that help us to identity and replicate the issue.
Specify the configuration of your environment. Include which operating system you use and the versions of runtime environments.
Attach logs, screenshots and exceptions, in possible.
Reveal the steps you took to reproduce the problem.