| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Previously, this case would cause arti-bench to hang forever, trying
to bootstrap against one network while another network was running.
|
| |
|
|
| |
(An empty $RUST_LOG no output, and confuse the nickm^Wuser.)
|
| |
|
|
|
| |
shellcheck doesn't like `export FOO="$(bar)"` as one line, since it
has the possibility of missing errors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new `arti-bench` crate does a simple end-to-end benchmark test
embedding Arti: it generates some random data (of configurable amount,
depending on command-line parameters), and then sends said data back and
forth via Arti (which should be configured to use a local Chutney
network).
Additionally, the benchmark can also be run via a local SOCKS5 server
(in order to benchmark the performance via a local Chutney node, for
comparison).
The `tests/chutney/arti-bench.sh` sets up and tears down Chutney as
required to make this work.
This is very much a first cut; there are many things that should
eventually get added, such as support for multiple connections, JSON
output capabilities, running multiple tests, ...
|
| |
|
|
| |
This is per a suggestion from @trinity-1686a.
|
| |
|
|
|
| |
Previously, if the arti process had died or been killed, we wouldn't
reach the point where we called "chutney stop".
|
| |
|
|
|
|
|
|
| |
If the user has CHUTNEY_PATH set, respect that value, rather than
cloning a local chutney.
Also, if we have a local chutney, then update it in case there have
been changes.
|
| |
|
