📐
Performance testing
Determine how your expected workload will perform on the Tashi Platform.
If you have an idea of what your data transfer profile will look like then you can deploy our metrics tools to generate similar network traffic and capture network statistics.
The Tashi Consensus Engine is already fast, but it's still in early development and we expect to be able to make some more progress soon. Reach out to us with your specific requirements so we can better target our optimizations.
The
capture tool will join a Tashi Network session and write metrics to a JSON file. The deployment kind of the Tashi Network doesn't matter - whether it's a production environment, or a feasibility test of other tools in generate mode.The
generate will join a Tashi Network session and transmit data according to the specified TOML configuration file. This mode is intended to simulate your intended workload before you start integrating with the Tashi Platform.For example data configuration profiles, see the
profiles directory in the release archive.For now the entire Tashi Network must be specified upfront. This file is required by both the
capture and generate tools. An example is included in the release archive.The config file must describe all participants within the Tashi network, including the nodes running the capture or generate tools.
It expects it secret key to be
secret.pem in the current working directory, which can be generated with the following command:openssl ecparam -name secp256k1 -genkey -noout -out secret.pem
The public key can be printed using:
openssl ec -in secret.pem -pubout
The first argument of both the
capture and generate tools indicates which peers entry from the network.toml file to use as its own configuration, for example:./capture me
The tools support the
RUST_LOG environment variable as described above, but not the RUST_LOG_PATH variable.Here’s an example of the captured output, not that time is measured in nanoseconds and timestamps are nanoseconds since the UNIX epoch.
[
{
"newest_event_timestamp": 1675702751425749766,
"events_without_consensus": 785,
"events_with_consensus": 754,
"lowest_time_until_consensus": 1238711,
"mean_time_until_consensus": 9716294,
"highest_time_until_consensus": 200615594,
"transactions_created": 0,
"total_data_created": 0,
"lowest_data_per_event": 0,
"highest_data_per_event": 0
},
{
"newest_event_timestamp": 1675702752433802288,
"events_without_consensus": 585,
"events_with_consensus": 576,
"lowest_time_until_consensus": 1433343,
"mean_time_until_consensus": 7065735,
"highest_time_until_consensus": 54990545,
"transactions_created": 0,
"total_data_created": 0,
"lowest_data_per_event": 0,
"highest_data_per_event": 0
}
]
You can use the
generate tool to periodically send data to the network. You can even have different nodes on the network generate different workloads. Like the capture tool, the generate tool expects network.toml and a secret.pem, but it also expects a workload definition file. You can find some example profiles in metrics-*.zip.$ ls
network.toml
secret.pem
fps-30.toml
$ ./macos/generate player1 fps-30.toml
Last modified 3mo ago