https://github.com/thin-edge/tedge-benchmark
thin-edge.io benchmark script (not intended for public consumption just yet)
https://github.com/thin-edge/tedge-benchmark
community iot thin-edge
Last synced: about 1 year ago
JSON representation
thin-edge.io benchmark script (not intended for public consumption just yet)
- Host: GitHub
- URL: https://github.com/thin-edge/tedge-benchmark
- Owner: thin-edge
- License: apache-2.0
- Created: 2023-12-06T21:43:21.000Z (over 2 years ago)
- Default Branch: main
- Last Pushed: 2024-06-20T14:27:45.000Z (almost 2 years ago)
- Last Synced: 2025-01-30T12:19:45.899Z (over 1 year ago)
- Topics: community, iot, thin-edge
- Language: Python
- Homepage:
- Size: 680 KB
- Stars: 0
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# tedge-benchmark
## Plugin summary
Benchmarking script which is run periodically using a systemd timer.
**Technical summary**
The following details the technical aspects of the plugin to get an idea what systems it supports.
|||
|--|--|
|**Languages**|`python3`|
|**CPU Architectures**|`all/noarch`. Not CPU specific|
|**Supported init systems**|`systemd`|
|**Required Dependencies**|python3-paho-mqtt|
|**Optional Dependencies (feature specific)**|-|
### How to do I get it?
The following linux package formats are provided on the releases page and also in the [tedge-community](https://cloudsmith.io/~thinedge/repos/community/packages/) repository:
|Operating System|Repository link|
|--|--|
|Debian/Raspbian (deb)|[](https://cloudsmith.io/~thinedge/repos/community/packages/detail/deb/tedge-benchmark/latest/a=all;d=any-distro%252Fany-version;t=binary/)|
|Alpine Linux (apk)|[](https://cloudsmith.io/~thinedge/repos/community/packages/detail/alpine/tedge-benchmark/latest/a=noarch;d=alpine%252Fany-version/)|
|RHEL/CentOS/Fedora (rpm)|[](https://cloudsmith.io/~thinedge/repos/community/packages/detail/rpm/tedge-benchmark/latest/a=noarch;d=any-distro%252Fany-version;t=binary/)|
### What will be deployed to the device?
* The following service will be installed
* `tedge-benchmark` (service and timer) (triggered every hour on the hour)
* `tedge-benchmark.py` script which is called from the service, however it can also be called manually for adhoc usage
## Plugin Dependencies
The following packages are required to use the plugin:
* tedge
### Check the timer status
You can check when the next time the benchmark will run by using the following systemd command:
```sh
systemctl status tedge-benchmark.timer
```
**Output**
```sh
● tedge-benchmark.timer - thin-edge.io benchmark runner
Loaded: loaded (/lib/systemd/system/tedge-benchmark.timer; enabled; preset: enabled)
Active: active (waiting) since Wed 2023-12-06 22:33:01 CET; 55min ago
Trigger: Thu 2023-12-07 00:00:00 CET; 31min left
Triggers: ● tedge-benchmark.service
Dec 06 22:33:01 rackfslot1 systemd[1]: Started tedge-benchmark.timer - thin-edge.io benchmark runner.
```
### Triggering the benchmark on demand
You can manually trigger the benchmark to run on demand using the following command:
```sh
systemctl start tedge-benchmark.service
```
Otherwise, you can also trigger the benchmark on the commands line.
```sh
tedge-benchmark.py run --count 1000 --beats 100 --period 500
```
### Check benchmark output
Check the results of the benchmark using:
```sh
tail -f /var/log/tedge-benchmark/tedge-benchmark.log
```
## About the benchmark script itself
See the [cli documentation](docs/cli/benchmark.md) for a print out of the usage.
The benchmark script is used to generate load on thin-edge.io by telemetry data on the thin-edge.io MQTT topic. The benchmark then checks to see if the telemetry data is mapped correctly to the Cumulocity outgoing topic to see if any messages are dropped.
The telemetry data creation can be controlled in the following ways,
* how many data points should be published in a burst (via `--beats `)
* how long to wait between publishing a single data point (via `--beats-delay `)
* how long to wait between bursts (from start of one burst to the start of another burst (via `--period `)
* how many data points are to be published in the entire test (across all bursts) (via `--count `)
* how many times to repeat all of the above (via `--iterations `)
The diagram aims at clarifying the terms listed above to better visualize which each of the parameters control:
