IntenseFinance/nosqlbench
3
0
Fork 0
mirror of https://github.com/nosqlbench/nosqlbench.git synced 2025-02-25 18:55:28 -06:00
Code Issues Packages Projects Releases Wiki Activity

license fixes

Browse Source
This commit is contained in:
Jonathan Shook
2025-01-08 14:24:58 -06:00
parent fce03c91eb
commit 5ec29a9166
3 changed files with 54 additions and 124 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
nb-engine/nb-engine-cli/src/main/java/io/nosqlbench/engine/cli/NBCLIOptions.java
View File

@@ -744,15 +744,13 @@ public class NBCLIOptions {
final String helpmsg = """ final String helpmsg = """
Could not recognize command 'ARG'. Could not recognize command 'ARG'.
This means that all of the following searches for a compatible command failed: This means that all of the following searches for a compatible command failed:
1. commands: no scenario command named 'ARG' is known. (start, run, await, ...) 1. commands: no command named 'ARG' is known. (start, run, await, ...)
2. scripts: no auto script named './scripts/auto/ARG.js' in the local filesystem.
3. scripts: no auto script named 'scripts/auto/ARG.js' was found in the PROG binary.
4. workloads: no workload file named ARG[.yaml] was found in the local filesystem, even in include paths INCLUDES. 4. workloads: no workload file named ARG[.yaml] was found in the local filesystem, even in include paths INCLUDES.
5. workloads: no workload file named ARG[.yaml] was bundled in PROG binary, even in include paths INCLUDES. 5. workloads: no workload file named ARG[.yaml] was bundled in PROG binary, even in include paths INCLUDES.
6. apps: no application named ARG was bundled in PROG. 6. apps: no application named ARG was bundled in PROG.
You can discover available ways to invoke PROG by using the various --list-* commands: You can discover available ways to invoke PROG by using the various --list-* commands:
[ --list-commands, --list-scripts, --list-workloads (and --list-scenarios), --list-apps ] [ --list-commands, --list-drivers, --list-workloads (and --list-scenarios), --list-apps ]
""" """
.replaceAll("ARG", cmdParam) .replaceAll("ARG", cmdParam)
.replaceAll("PROG", "nb5") .replaceAll("PROG", "nb5")

9
nb-engine/nb-engine-cli/src/main/resources/basic.md
View File

@@ -4,21 +4,12 @@
# for a list of available topics run # for a list of available topics run
./nb help topics ./nb help topics
# to see the web based docs run
./nb docserver
# To run a simple built-in workload run: # To run a simple built-in workload run:
./nb cql-iot ./nb cql-iot
# To get a list of scenarios to run: # To get a list of scenarios to run:
./nb --list-scenarios ./nb --list-scenarios
# To get a list of scripts to run:
./nb --list-scripts
# To provide your own contact points (comma separated), add the hosts= parameter
./nb cql-iot hosts=host1,host2
# Details on all command line options are available with # Details on all command line options are available with
./nb help commandline ./nb help commandline

163
nb-engine/nb-engine-cli/src/main/resources/cli-scripting.md
View File

@@ -1,31 +1,60 @@
Running Activities and Scenarios via CLI # Command Line Scripting
========================================
${PROG} always runs a scenario script. However, there are multiple ways to tell Each NoSQLBench session runs a series of commands. Some of these commands
${PROG} what that script should be. may run asynchronously, like a background process, while other commands
run in the foreground. This allows some commands to act as orchestration
controls over others which act more like persistent processes. This occurs
entirely within the NoSQLBench process.
Any argument in name=value format serves as a parameter to the Each command runs within a specific container, which encapsulates configuration,
script or activity that precedes it. state, and visibility of results into episodes or partitions. This is useful
for testing scenarios which may have separately named stages or similar.
To create a scenario script that simply runs a single activity to completion, The primary way to feed commands to a NoSQLBench session is via command line scripting.
use this format: All this means is that you are providing a series of valid commands which are
~~~ implemented internally by nb5, and which execute in the order presented.
${PROG} activity <param>=<value> [...]
~~~
To create a scenario script that runs multiple activities concurrently, Apart from the activity related commands, all commands are synchronous, as if they
simply add more activities to the list: were simply a script. Activities can be *run* synchronously with respect to other
~~~ commands, or they can be *start*ed asynchronously and then managed by other commands
${PROG} activity <param>=<value> [...] activity <param>=<value> [...] afterwards.
~~~
To execute a scenario script directly, simply use the format: ## Conventions
~~~
${PROG} script <scriptname> [param=value [...]] Any argument in name=value format serves as a parameter to the script or activity that precedes it.
~~~
Commands can be specified one after another in a continuous stream of _command_
_paramname_=_paramvalue_ ... without ambiguity.
## Examples
To run a single activity:
```
${PROG} run <param>=<value> [...]
```
To run multiple activities serially:
```
${PROG} run <param>=<value> [...] run <param>=<value> [...]
```
## Available Commands
To see the list of available commands, simply:
```
${PROG} --list-commands
```
To get help on any one of these commands, simply:
```
${PROG} help <command>
```
These can all be used on the command line in any order. By combining these activity commands on
the command line, you can construct a non-trivial testing scenarios, like control activity
sequencing and concurrency, etc.
## Time & Size Units
Time & Size Units
=================
Anywhere you need to specify a time, you can use standard unit suffixes, Anywhere you need to specify a time, you can use standard unit suffixes,
like "1 day", "1m", etc. Both long names and short names work in any like "1 day", "1m", etc. Both long names and short names work in any
case. The valid time suffixes are ns, us, ms, s, m, h, d, w, y, for case. The valid time suffixes are ns, us, ms, s, m, h, d, w, y, for
@@ -33,93 +62,5 @@ nanoseconds, microseconds, milliseconds, seconds, minutes, hours,
days, weeks, or years, respectively. days, weeks, or years, respectively.
As well, when specifying sizes, standard SI and IEC units apply for suffixes like As well, when specifying sizes, standard SI and IEC units apply for suffixes like
KB, KiB. For more details, see KB, KiB. For more details, see [The Wikipedia Page](https://en.wikipedia.org/wiki/Binary_prefix).
[The Wikipedia Page](https://en.wikipedia.org/wiki/Binary_prefix).
For Scenario Designers
======================
You can build up a complex scenario by combining scripts and activities.
If this scenario needs to have some cross-shared logic, that is up to you,
the scenario designer.
## Script Parameters
Any arguments following a script in name=value form will be used to parameterize
the script. Script parameters are simply macro tokens in the form &lt;&lt;NAME:default&gt;&gt;.
All such parameters in the script will be substituted before the script executes,
so parameters may be dropped into scripts ad-hoc.
## Session Names
By using the option --session-name <name>, you can name the session logfile
that will be (over)written with execution details.
~~~
${PROG} --session-name testsession42
~~~
## Metric Name
If you need to see what metrics are available for a particular activity type,
you can ask ${PROG} to instantiate an activity of that type and discover the
metrics, dumping out a list. The following form of the command shows you how
to make a list that you can copy metric names from for scripting. If you provide
an example activity alias that matches one of your scripts, you can use it exactly
as it appears.
~~~
${PROG} --list-metrics driver=diag alias=anexample
~~~
This will dump a list of metric names in the shortened format that is most suitable
for scenario script development. This format is required for the --list-metrics
option, but it should be familiar and easy to copy and paste from other command lines.
## Scripting on the command line
There are a few commands available on the command line to allow for basic control
of activities without having to edit the scenario script directly:
To start an activity without waiting for it to complete:
~~~
start <param>=<val> ...
~~~
To start an activity and then wait for it to complete before continuing:
~~~
run <pram>=<value> ...
~~~
To stop an activity by its alias while first waiting for a required thread (motor/slot) entering a specific SlotState:
~~~
stop <activity alias>
~~~
To stop an activity by its alias, without first waiting for a required thread (motor/slot) entering a specific SlotState:
~~~
forceStop <activity alias>
~~~
To wait for a particular activity that has been started to complete before continuing:
~~~
await <activity alias>
~~~
To wait for a number of milliseconds before continuing:
~~~
waitmillis <milliseconds>
~~~
To add a script fragment to the scenario script:
~~~
fragment '<ecmascript>...'
~~~
These can all be used on the command line in any order. The scenario script is assembled
from them before it is executed. If you want to see the resulting script, use the
--show-script option to dump the script to the console instead of running it.
By combining these activity commands on the command line, you can construct a non-trivial
scenario from other snippets, control activity sequencing and concurrency, etc. This does
not replace what is possible for direct scripting, but it does allow for many custom
test scenarios without it. If you want to do more advanced scripting, please consult
the scenario designers guide.