latencies: an array of latencies to set on the provider side.
bandwidths: an array of bandwidths (egress per second) to set on the provider side.
It supports two groups:
providers, max instance 1.
requestors, as many as needed, right now testing with 1.
Both provider and requestor will do an iteration for every latency x bandwidth tuple.
For every iteration, the provider generates a new random file, and publishes the CID to a sync topic. It then sets the network latency for that round. The requestor awaits the CID, and also awaits for the network to be configured, and then performs a graphsync request for the CID.
$ testground daemon # start the testground daemon in one tab
$ git clone https://github.com/filecoin-project/oni.git
$ cd oni
$ testground plan import --from graphsync
created symlink /Users/raul/testground/plans/graphsync -> graphsync
imported plans:
graphsync stress
$ testground run composition -f ./graphsync/_compositions/stress.toml
...
TODO
All readings seem to be the same. This is odd. I think graphsync works asynchronously, but I'm not waiting for each request to complete. @hannahhoward?
A stress test that takes three parameters:
It supports two groups:
providers, max instance 1.requestors, as many as needed, right now testing with 1.Both provider and requestor will do an iteration for every latency x bandwidth tuple.
For every iteration, the provider generates a new random file, and publishes the CID to a sync topic. It then sets the network latency for that round. The requestor awaits the CID, and also awaits for the network to be configured, and then performs a graphsync request for the CID.
Instructions
To run, first install testground as indicated in the Testground README.
Then clone this repo and this branch:
TODO
All readings seem to be the same. This is odd. I think graphsync works asynchronously, but I'm not waiting for each request to complete. @hannahhoward?