mirror of
https://github.com/nosqlbench/nosqlbench.git
synced 2025-02-25 18:55:28 -06:00
license fixes
This commit is contained in:
Jonathan Shook
parent
fce03c91eb
commit
5ec29a9166
@ -744,15 +744,13 @@ public class NBCLIOptions {
|
||||
final String helpmsg = """
|
||||
Could not recognize command 'ARG'.
|
||||
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, ...)
|
||||
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.
|
||||
1. commands: no command named 'ARG' is known. (start, run, await, ...)
|
||||
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.
|
||||
6. apps: no application named ARG was bundled in PROG.
|
||||
|
||||
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("PROG", "nb5")
|
||||
|
||||
@ -4,21 +4,12 @@
|
||||
# for a list of available topics run
|
||||
./nb help topics
|
||||
|
||||
# to see the web based docs run
|
||||
./nb docserver
|
||||
|
||||
# To run a simple built-in workload run:
|
||||
./nb cql-iot
|
||||
|
||||
# To get a list of scenarios to run:
|
||||
./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
|
||||
|
||||
./nb help commandline
|
||||
|
||||
@ -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
|
||||
${PROG} what that script should be.
|
||||
Each NoSQLBench session runs a series of commands. Some of these commands
|
||||
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
|
||||
script or activity that precedes it.
|
||||
Each command runs within a specific container, which encapsulates configuration,
|
||||
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,
|
||||
use this format:
|
||||
~~~
|
||||
${PROG} activity <param>=<value> [...]
|
||||
~~~
|
||||
The primary way to feed commands to a NoSQLBench session is via command line scripting.
|
||||
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.
|
||||
|
||||
To create a scenario script that runs multiple activities concurrently,
|
||||
simply add more activities to the list:
|
||||
~~~
|
||||
${PROG} activity <param>=<value> [...] activity <param>=<value> [...]
|
||||
~~~
|
||||
Apart from the activity related commands, all commands are synchronous, as if they
|
||||
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
|
||||
afterwards.
|
||||
|
||||
To execute a scenario script directly, simply use the format:
|
||||
~~~
|
||||
${PROG} script <scriptname> [param=value [...]]
|
||||
~~~
|
||||
## Conventions
|
||||
|
||||
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,
|
||||
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
|
||||
@ -33,93 +62,5 @@ nanoseconds, microseconds, milliseconds, seconds, minutes, hours,
|
||||
days, weeks, or years, respectively.
|
||||
|
||||
As well, when specifying sizes, standard SI and IEC units apply for suffixes like
|
||||
KB, KiB. For more details, see
|
||||
[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 <<NAME:default>>.
|
||||
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.
|
||||
KB, KiB. For more details, see [The Wikipedia Page](https://en.wikipedia.org/wiki/Binary_prefix).
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user