diff --git a/docs/quickstart.md b/docs/quickstart.md index 4fcdcb6ec8e33ee490db41e629ff8da84c1e8506..6effc0cb288c01d28267b12e360c603f17641d32 100644 --- a/docs/quickstart.md +++ b/docs/quickstart.md @@ -74,4 +74,4 @@ All you need to get started is access to a Kubernetes cluster plus kubectl and H * [Deploy and run custom benchmarks](running-benchmarks) * [Define your own benchmarks](creating-a-benchmark) -* [Customize the Theodolite Installation](installation) +* [Customize the Theodolite installation](installation) diff --git a/docs/running-benchmarks.md b/docs/running-benchmarks.md index d999e75cb4f4f4f6c0858809aa71aaf86e0b0b3a..309915fa4dfcd5362e7901e197e07c1d532977db 100644 --- a/docs/running-benchmarks.md +++ b/docs/running-benchmarks.md @@ -23,7 +23,7 @@ These files are usually provided by benchmark designers. For example, we ship Theodolite with a set of [benchmarks for event-driven microservices](theodolite-benchmarks). Alternatively, you can also [create your own benchmarks](creating-a-benchmark). -Suppose your Benchmark is defined in `example-benchmark.yaml` and all resources required by this benchmark are bundled in `example-configmap.yaml`. +Suppose your benchmark is defined in `example-benchmark.yaml` and all resources required by this benchmark are bundled in `example-configmap.yaml`. You can deploy both to Kubernetes by running: ```sh @@ -44,7 +44,7 @@ NAME AGE STATUS example-benchmark 81s Ready ``` -The status of a benchmark tells you whether executions of it can be executed: +The status of a benchmark tells you whether executions of it are ready to run: * *Ready* means that Theodolite has access to all resources referred from the benchmark. * *Pending* implies that not all benchmark resources are available (yet). Please ensure that you have deployed them, for example, by running `kubectl get configmaps`. @@ -102,7 +102,7 @@ The output is similar to this: ``` NAME STATUS DURATION AGE -theodolite-example-execution RUNNING 13s 14s +theodolite-example-execution Running 13s 14s ``` The `STATUS` field will tell you whether a benchmark execution has been diff --git a/docs/theodolite-benchmarks/index.md b/docs/theodolite-benchmarks/index.md index 39db8873e665a7399b144936998f59925289c505..9b08e6f5f2fe049c17dce819b7c4d9b83fcbc12e 100644 --- a/docs/theodolite-benchmarks/index.md +++ b/docs/theodolite-benchmarks/index.md @@ -20,7 +20,7 @@ A simple, but common use case in event-driven architectures is that events or me Another common use case for stream processing architectures is reducing the amount of events, messages, or measurements by aggregating multiple records within consecutive, non-overlapping time windows. Typical aggregations compute the average, minimum, or maximum of measurements within a time window or count the occurrence of same events. Such reduced amounts of data are required, for example, to save computing resources or to provide a better user experience (e.g., for data visualizations). -When using aggregation windows of ï¬xed size that succeed each other without gaps (called [tumbling windows](https://kafka.apache.org/20/documentation/streams/developer-guide/dsl-api.html#tumbling-time-windows) in many stream processing engines), the (potentially varying) message frequency is reduced to a constant value. +When using aggregation windows of ï¬xed size that succeed each other without gaps (called [tumbling windows](https://kafka.apache.org/30/documentation/streams/developer-guide/dsl-api.html#tumbling-time-windows) in many stream processing engines), the (potentially varying) message frequency is reduced to a constant value. This is also referred to as downsampling. Downsampling allows for applying many machine learning methods that require data of a ï¬xed frequency.