* feat: add new implementation versions (go)
* ci: generalise adding new implementation versions
* ci: automate new version addition for rust-libp2p and js-libp2p
Our current throughput tests open a connection, open a stream,
up- or download 100MB and close the connection. 100 MB is not enough on the
given path (60ms, ~5gbit/s) to exit congestion controller's slow-start. See
https://github.com/libp2p/test-plans/issues/261 for details.
Instead of downloading 100MB multiple times, each on a new connection, establish
a single connection and continuously measure the throughput for a fixed
duration (20s).
- Upgrade rust-libp2p `v0.52` implementation to rust-libp2p `v0.52.3`.
- Remove rust-libp2p `master` implementation. Given that `v0.52.3` contains the
stable QUIC implementation, there is no more need for `master`.
On root the nvm install script can not find a shell config.
```
=> Profile not found. Tried ~/.bashrc, ~/.bash_profile, ~/.zprofile, ~/.zshrc, and ~/.profile.
```
Our perf terraform setup differentiates in long lived and short lived resources.
On CI, our long lived resources are spun up once and our short lived resources
are spun up on each CI run. From time to time we have to adjust the long lived
resources. End result is a new launch template that needs to be referenced in
the short lived resources by version.
Next to our CI, the perf terraform setup can as well be used on personal AWS
accounts. Their long lived launch template version likely doesn't match the
configured launch template version of the short lived aws_instance.
Instead of specifying a specific version, instruct terraform to use the default,
thus supporting both our CI and personal AWS account use-case.
Previously only the maximum udp **receive** buffer size was increased to
`2500000` bytes. With this commit both the send and the receive buffer size is increase.
This commit makes iperf use TCP instead of UDP. Using UDP allows the sender to
send as much data as they can, not as much data as the receiver can handle.
Using TCP measures the actual bandwidth of the connection.
This commit sets the TCP send and receive window to the bandwidth-delay-product.
In order to exhaust the whole bandwidth between the two nodes, TCP needs to be
able to buffer all bytes on the wire in the case of packet loss.
With https://github.com/libp2p/rust-libp2p/pull/3454 merged we can now test the
new rust-libp2p QUIC implementation based on upstream quinn directly from
rust-libp2p `master`.
This commit does the following in libp2p/test-plans:
1. Remove the `perf/impl/rust-libp2p-quinn` implementation.
2. Introduce the `perf/impl/rust-libp2p/master` version of the rust-libp2p implementation.
We can promote the latter to a proper version on the next rust-libp2p release.
- Increase upload/download benchmark iterations. Still conservative value of `10` due to slow rust-libp2p tcp. See https://github.com/libp2p/rust-yamux/issues/162. Note however that this is 10x an upload of 100MB.
- Increase latency benchmark iterations.
- When experimenting with increasing iterations, instances are taken down
prematurely. See e.g. https://github.com/libp2p/test-plans/actions/runs/5418669631/jobs/9850992882
- When benchmarking from a local developer machine, experimenting for longer is useful.
- The AWS Lambda is only a safety net machanism. In the rare case where we
miss to clean up, running the machines for <1h or 2h doesn't matter cost wise.
This project includes the following components:
- `terraform/`: a Terraform scripts to provision infrastructure
- `impl/`: implementations of the [libp2p perf
protocol](https://github.com/libp2p/specs/blob/master/perf/perf.md) running on
top of e.g. go-libp2p, rust-libp2p or Go's std-library https stack
- `runner/`: a set of scripts building and running the above implementations on
the above infrastructure, reporting the results in `benchmark-results.json`
Benchmark results can be visualized with
https://observablehq.com/@mxinden-workspace/libp2p-performance-dashboard.
Co-authored-by: Marco Munizaga <git@marcopolo.io>
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
Co-authored-by: Piotr Galar <piotr.galar@gmail.com>
Piotr Galar
Max Inden
Alex Potsides
Chad Nehemiah
github-actions[bot]
Steve Loeppky