space to a non-zero number will effectively format the JSON output with indentations on multiple lines. This could “spam” the console a bit (not a problem for log files, unless you care about the extra newlines).
@@ -227,7 +227,7 @@ For example, to disable the `mylogger1` target, the following approaches are ava
### Overriding logger target settings
-But what if you would like to modify one of the options of a transport? You can use a [configuration file](https://hyperledger.github.io/caliper/v0.6.0/reference/untime-config/#configuration-files) for that!
+But what if you would like to modify one of the options of a transport? You can use a [configuration file](runtime-config.md/#configuration-files) for that!
For the next example, we will disable the default file logger, modify the logging level of the console target, and also add a new daily rotating file logger. We can do all of this with a single configuration file.
@@ -270,7 +270,7 @@ If you save the above content as `caliper.yaml` in your workspace directory, the
1. We only set the properties we wanted to override. The default configuration file will be merged with the above configuration file, the values in the latter taking precedence.
2. The provided options for a transport are not verified by Caliper. It is simple passed to the specific transport. It is your responsibility to configure the transport the right way.
- 3. We could have disabled the file logger also from the command line, or from an environment variable. The reason we did it from a config file is explained in the [Tips & tricks](https://hyperledger.github.io/caliper/v0.6.0/reference/logging/#tips--tricks) section.
+ 3. We could have disabled the file logger also from the command line, or from an environment variable. The reason we did it from a config file is explained in the [Tips & tricks](#tips-tricks) section.
## Creating your own loggers
@@ -477,7 +477,7 @@ To this end, the ability to override the logging style settings from the command
The easiest way to do that is with a project-level configuration file. If you name the following file `caliper.yaml` and place it in your workspace root, then Caliper will automatically apply the settings.
!!! note
- there are other ways to load a configuration file, as discussed in the [runtime configuration page](https://hyperledger.github.io/caliper/v0.6.0/runtime-config/#configuration-files).
+ there are other ways to load a configuration file, as discussed in the [runtime configuration page](runtime-config.md/#configuration-files).
```sh
caliper:
@@ -511,4 +511,4 @@ caliper:
## License
-The Caliper codebase is released under the [Apache 2.0 license](https://hyperledger.github.io/caliper/v0.6.0/general/license/). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
+The Caliper codebase is released under the [Apache 2.0 license](../getting-started/license.md). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
diff --git a/docs/source/concepts/rate-controllers.md b/docs/source/concepts/rate-controllers.md
index ac91333e7..59f809040 100644
--- a/docs/source/concepts/rate-controllers.md
+++ b/docs/source/concepts/rate-controllers.md
@@ -1,16 +1,16 @@
The rate at which transactions are input to the blockchain system is a key factor within performance tests. It may be desired to send transactions at a specified rate or follow a specified profile. Caliper permits the specification of custom rate controllers to enable a user to perform testing under a custom loading mechanism. A user may specify their own rate controller or use one of the default options:
-- [Fixed rate](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#fixed-rate)
-- [Fixed feedback rate](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#fixed-feedback-rate)
-- [Fixed load](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#fixed-load)
-- [Maximum rate](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#maximum-rate)
-- [Linear rate](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#linear-rate)
-- [Composite rate](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#composite-rate)
-- [Zero rate](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#zero-rate)
-- [Record rate](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#record-rate)
-- [Replay rate](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#replay-rate)
-
-For implementing your own rate controller, refer to the [Adding Custom Controllers](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#adding-custom-controllers) section.
+- [Fixed rate](#fixed-rate)
+- [Fixed feedback rate](#fixed-feedback-rate)
+- [Fixed load](#fixed-load)
+- [Maximum rate](#maximum-rate)
+- [Linear rate](#linear-rate)
+- [Composite rate](#composite-rate)
+- [Zero rate](#zero-rate)
+- [Record rate](#record-rate)
+- [Replay rate](#replay-rate)
+
+For implementing your own rate controller, refer to the [Adding Custom Controllers](#adding-custom-controllers) section.
## Fixed rate
The fixed rate controller is the most basic controller, and also the default option if no controller is specified. It will send input transactions at a fixed interval that is specified as TPS (transactions per second).
@@ -135,7 +135,7 @@ The following example specifies a rate controller that gradually changes the tra
```
!!!note
- similarly to the [fixed rate controller](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#fixed-rate), this controller also divides the workload between the available client, so the specified rates in the configuration are cumulative rates, and not the rates of individual clients. Using the above configuration with 5 clients results in clients that start at 5 TPS and finish at 15 TPS. Together they generate a [25-75] TPS load.
+ similarly to the [fixed rate controller](#fixed-rate), this controller also divides the workload between the available client, so the specified rates in the configuration are cumulative rates, and not the rates of individual clients. Using the above configuration with 5 clients results in clients that start at 5 TPS and finish at 15 TPS. Together they generate a [25-75] TPS load.
## Composite rate
A benchmark round in Caliper is associated with a single rate controller. However, a single rate controller is rarely sufficient to model advanced client behaviors. Moreover, implementing new rate controllers for such behaviors can be cumbersome and error-prone. Most of the time a complex client behavior can be split into several, simpler phases.
@@ -162,7 +162,7 @@ Note, that technically, composite rate controllers can be nested to form a hiera
- `logChange`: a `boolean` value indicating whether the switches between the specified rate controllers should be logged or not.
-For example, the definition of a square wave function (with varying amplitude) as the transaction submission rate is as easy as switching between [fixed rate](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#fixed-rate) controllers with different TPS settings:
+For example, the definition of a square wave function (with varying amplitude) as the transaction submission rate is as easy as switching between [fixed rate](#fixed-rate) controllers with different TPS settings:
```sh
{
@@ -197,7 +197,7 @@ For example, the definition of a square wave function (with varying amplitude) a
The results of recently finished transactions are propagated to the sub-controllers as-is, so for the first few call of a newly activated sub-controller it can receive recent results that don’t belong to its virtualized round.
-This virtualization does not affect the memoryless controllers, i.e., the controllers whose control logic does not depend on global round properties or past transaction results. However, other controllers might exhibit some strange (but hopefully transient) behavior due to this “virtualized” round approach. For example, the logic of the [PID controller](https://hyperledger.github.io/caliper/v0.6.0/reference/ate-controllers/#pid-rate) for example depends on the transaction backlog.
+This virtualization does not affect the memoryless controllers, i.e., the controllers whose control logic does not depend on global round properties or past transaction results. However, other controllers might exhibit some strange (but hopefully transient) behavior due to this “virtualized” round approach. For example, the logic of the PID controller for example depends on the transaction backlog.
## Zero rate
@@ -205,7 +205,7 @@ This virtualization does not affect the memoryless controllers, i.e., the contro
This controller stops the workload generation for the duration of the round.
### Options and use
-Using the controller on its own for a round is meaningless. However, it can be used as a building block inside a [composite rate](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/#composite-rate) controller. **The zero rate controller can be used only in duration-based rounds!**
+Using the controller on its own for a round is meaningless. However, it can be used as a building block inside a [composite rate](#composite-rate) controller. **The zero rate controller can be used only in duration-based rounds!**
```sh
{
@@ -242,7 +242,7 @@ The controller is identified by the `zero-rate` string as the value of the `type
## Record rate
This rate controller serves as a decorator around an other (arbitrary) controller. Its purpose is to record the times (relative to the start of the round) when each transaction was submitted, i.e., when the transaction was “enabled” by the “sub-controller.”
-The following example records the times when the underlying [fixed rate](https://hyperledger.github.io/caliper/v0.6.0/reference.rate-controllers/#fixed-rate) controller enabled the transactions (for details, see the available options below the example):
+The following example records the times when the underlying [fixed rate](#fixed-rate) controller enabled the transactions (for details, see the available options below the example):
```sh
{
@@ -321,11 +321,11 @@ The replay rate controller can be specified by setting the rate controller type
- `pathTemplate`: the template for the file path where the transaction timings will be replayed from. The path can be either an absolute path or relative to the root Caliper directory.
-The template can (**and should**) contain special “variables/placeholders” that can refer to special environment properties (see the remarks at the [record rate controller](https://hyperledger.github.io/caliper/v0.6.0/reference.rate-controllers/#record-rate)). The available placeholders are the following:
+The template can (**and should**) contain special “variables/placeholders” that can refer to special environment properties (see the remarks at the [record rate controller](#record-rate)). The available placeholders are the following:
- `` | string | The error message in case the endorser peer `
` returned an error as endorsement result. | | `endorsement_result_
` | Buffer | The encoded contract invocation result returned by the endorser peer `
`. It is the user callback’s responsibility to decode the result. | -| `endorsement_verify_error_
` | string | Has the value of 'INVALID' if the signature and identity of the endorser peer `
` couldn’t be verified. This verification step can be switched on/off through the [runtime configuration options](https://hyperledger.github.io/caliper/v0.6.0/connector-configuration/fabric-config/#runtime-settings). | +| `endorsement_verify_error_
` | string | Has the value of 'INVALID' if the signature and identity of the endorser peer `
` couldn’t be verified. This verification step can be switched on/off through the [runtime configuration options](#runtime-settings). | | `endorsement_result_error
` | string | If the transaction proposal or query execution at the endorser peer `
` results in an error, this field contains the error message. |
| `read_write_set_error` | string | Has the value of 'MISMATCH' if the sent transaction proposals resulted in different read/write sets. |
| `time_orderer_ack` | number | The Unix epoch when the adapter received the confirmation from the orderer that it successfully received the transaction. Note, that this isn’t the actual ordering time of the transaction. |
@@ -239,7 +239,7 @@ The `cleanupWorkloadModule` function is called at the end of the round, and can
## Network configuration file reference
The YAML network configuration file of the adapter mainly describes the organizations and the identities associated with those organizations, It also provides explicit information about the channels in your Fabric network and the chaincode (containing 1 or more smart contracts) deployed to those channels. It can reference Common Connection Profiles for each organization (as common connection profiles are specific to a single organization). These are the same connection profiles that would be consumed by the node-sdk. Whoever creates the Fabric network and channels would be able to provide appropriate profiles for each organization.
-The following sections detail each part separately. For a complete example, please refer to the [example section](https://hyperledger.github.io/caliper/v0.6.0/connector-configuration/fabric-config/#network-configuration-example) or one of the files in the [Caliper repositor](https://github.com/hyperledger/caliper), such as the caliper-fabric test folder.
+The following sections detail each part separately. For a complete example, please refer to the [example section](#network-configuration-example) or one of the files in the [Caliper repositor](https://github.com/hyperledger/caliper), such as the caliper-fabric test folder.
name
@@ -1057,4 +1057,4 @@ organizations:
## License
-The Caliper codebase is released under the [Apache 2.0 license](https://hyperledger.github.io/caliper/v0.6.0/general/license/). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
+The Caliper codebase is released under the [Apache 2.0 license](../getting-started/license.md). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
diff --git a/docs/source/connectors/writing-connectors.md b/docs/source/connectors/writing-connectors.md
index 5ac6c145e..ae1ceb770 100644
--- a/docs/source/connectors/writing-connectors.md
+++ b/docs/source/connectors/writing-connectors.md
@@ -4,9 +4,9 @@ Connectors are probably the most important modules in Caliper. They provide an a
!!! note
- *To get a sense of how a connector fits into the Caliper architecture, see the corresponding architecture documentation sections about [multi-platform support](https://hyperledger.github.io/caliper/v0.6.0/overview/architecture/#multi-platform-support), [the manager process](https://hyperledger.github.io/caliper/v0.6.0/overview/architecture/#the-manager-process) and [the worker processes](https://hyperledger.github.io/caliper/v0.6.0/overview/architecture/#the-worker-process).*
+ *To get a sense of how a connector fits into the Caliper architecture, see the corresponding architecture documentation sections about [multi-platform support](../getting-started/architecture.md/#multi-platform-support), [the manager process](../getting-started/architecture.md/#the-manager-process) and [the worker processes](../getting-started/architecture.md/#the-worker-process).*
-Caliper ships with some [predefined/built-in connectors](https://hyperledger.github.io/caliper/v0.6.0/overview/getting-started/#supported-blockchain-solutions), but in general, connectors are treated as pluggable components (just like resource and TX monitors, workload modules, etc.). So nothing stops you from implementing and using your 3rd party connector! However, we strongly recommend that you absorb every part of this guide before implementing a new connector.
+Caliper ships with some [predefined/built-in connectors](../index.md#supported-blockchain-solutions), but in general, connectors are treated as pluggable components (just like resource and TX monitors, workload modules, etc.). So nothing stops you from implementing and using your 3rd party connector! However, we strongly recommend that you absorb every part of this guide before implementing a new connector.
## Requirements for quality connectors
@@ -51,7 +51,7 @@ Regardless of the used API technology, there’s probably a mature client librar
## Implementing the connector
-You should treat a connector implementation process as a full-fledged Node.js project. Refer to the [Caliper integration](https://hyperledger.github.io/caliper/v0.6.0/reference/writing-connectors/#integration-with-caliper) section for the suggested project structure. Putting the project structure aside, you have four implementation-related tasks:
+You should treat a connector implementation process as a full-fledged Node.js project. Refer to the [Caliper integration](#integration-with-caliper) section for the suggested project structure. Putting the project structure aside, you have four implementation-related tasks:
1. Implement the connector interface (optionally using the available utility base class).
2. Implement a factory method for instantiating the connector.
@@ -79,7 +79,7 @@ module.exports = ConnectorInterface;
The interface is detailed in the next subsection, but for now, keep the following things in mind:
-1. The connector is used in two [different environments](https://hyperledger.github.io/caliper/v0.6.0/architecture/#caliper-processes): in the manager and worker processes. The corresponding environment of the methods will be discussed in the interface reference subsection.
+1. The connector is used in two [different environments](../getting-started/architecture.md#caliper-processes): in the manager and worker processes. The corresponding environment of the methods will be discussed in the interface reference subsection.
2. The connector must expose certain [events](https://nodejs.org/docs/latest-v10.x/api/events.html) about the requests, otherwise it’s not observable by the Caliper workers, which breaks the scheduling mechanism of Caliper.
3. `sendRequests` is the hot path for the interface, implement it carefully and efficiently!
4. The behavior of the connector (and the methods to really implement) largely depends on the capabilities of the network configuration schema. The more flexibility you allow on the Caliper-side of the network, the more features you will have to provide. A flexible connector makes it easier to setup benchmark scenarios, resulting in happy users.
@@ -211,7 +211,7 @@ The following is a possible implementation of a factory method for our `fast-led
### The network configuration file
-The [network configuration file](https://hyperledger.github.io/caliper/v0.6.0/overview/architecture/#network-configuration-file) can contain whatever information your connector requires to communicate with the SUT and fulfill the connector [quality requirements](https://hyperledger.github.io/caliper/v0.6.0/reference/writing-connectors/#requirements-for-quality-connectors). The configuration file can be either a JSON or YAML file. YAML is preferred for its readability and comment support.
+The [network configuration file](../getting-started/architecture.md#network-configuration-file) can contain whatever information your connector requires to communicate with the SUT and fulfill the connector [quality requirements](#requirements-for-quality-connectors). The configuration file can be either a JSON or YAML file. YAML is preferred for its readability and comment support.
The network configuration schema must contain a mandatory top-level field with the following structure:
@@ -226,11 +226,11 @@ caliper:
end: stopLedger.sh
```
-The `caliper.blockchain` attribute tells Caliper which connector to load for the test. The value of the attribute depends on how you want to [integrate the connector with Caliper](https://hyperledger.github.io/caliper/v0.6.0/reference/writing-connectors/#integration-with-caliper).
+The `caliper.blockchain` attribute tells Caliper which connector to load for the test. The value of the attribute depends on how you want to [integrate the connector with Caliper](#integration-with-caliper).
## Binding configuration
-The [binding](https://hyperledger.github.io/caliper/v0.6.0/overview/installing-caliper/#the-bind-command) command of Caliper allows you to specify major connector dependencies to be installed during runtime (instead of packaged with the connector during development time). SUT SDKs and other client libraries usually fall into this category (i.e., libraries that facilitate interactions with the SUT). If the APIs of such libraries are consistent across different versions, then your single connector implementation can possibly target multiple SUT versions.
+The [binding](../getting-started/installing-caliper.md/#the-bind-command) command of Caliper allows you to specify major connector dependencies to be installed during runtime (instead of packaged with the connector during development time). SUT SDKs and other client libraries usually fall into this category (i.e., libraries that facilitate interactions with the SUT). If the APIs of such libraries are consistent across different versions, then your single connector implementation can possibly target multiple SUT versions.
In that case, users should be able to select a specific SDK version that will target the corresponding SUT version. You can achieve this by providing a binding configuration file (JSON or YAML) for your connector.
@@ -287,7 +287,7 @@ Your connector can use such advanced specification to provide support for a wide
## Documenting the connector
-Providing proper user manual for your connector is just as important as a quality implementation. Otherwise, users will have a hard time interacting with your connector. We will take the [Fabric connector documentation](https://hyperledger.github.io/caliper/v0.6.0/reference/writing-connectors/Fabric_Configuration.md) as an example, section by section.
+Providing proper user manual for your connector is just as important as a quality implementation. Otherwise, users will have a hard time interacting with your connector. We will take the [Fabric connector documentation](fabric-config.md) as an example, section by section.
### Overview
@@ -306,13 +306,13 @@ However, it can happen that not every SUT feature is supported by every binding.
### Runtime settings
-The network configuration file only describes the SUT topology and related artifacts. SUT-agnostic design choices can still arise during the development of a connector. Instead of deciding yourself, you should delegate such choices to the end users utilizing the [runtime configuration mechanism](https://hyperledger.github.io/caliper/v0.6.0/reference/runtime-config/) of Caliper where possible/meaningful.
+The network configuration file only describes the SUT topology and related artifacts. SUT-agnostic design choices can still arise during the development of a connector. Instead of deciding yourself, you should delegate such choices to the end users utilizing the [runtime configuration mechanism](../concepts/runtime-config.md) of Caliper where possible/meaningful.
Such settings typically affect the operating mode of the connector, but don’t change the overall semantics of the SUT interactions. Be sure to document every available runtime setting for your connector! Also, don’t forget to provide sensible defaults to these settings where possible.
### Request API
-The main users of your connector will be workload module developers. They will interact with your connector mainly through the `[sendRequests](https://hyperledger.github.io/caliper/v0.6.0/reference/writing-connectors/#interface-reference)` method. The method accepts either a single, or multiple settings object relating to the requests the user wants to send. You have to precisely specify what kind of settings are available for a request. These will typically include:
+The main users of your connector will be workload module developers. They will interact with your connector mainly through the `[sendRequests](#interface-reference)` method. The method accepts either a single, or multiple settings object relating to the requests the user wants to send. You have to precisely specify what kind of settings are available for a request. These will typically include:
- The operation to execute on the SUT.
- The arguments of the operation.
@@ -393,4 +393,4 @@ const BuiltinConnectors = new Map([
## License
-The Caliper codebase is released under the [Apache 2.0 license](https://hyperledger.github.io/caliper/v0.6.0/general/license/). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
+The Caliper codebase is released under the [Apache 2.0 license](../getting-started/license.md). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
diff --git a/docs/source/getting-started/architecture.md b/docs/source/getting-started/architecture.md
index 77ab380c6..d787baa95 100644
--- a/docs/source/getting-started/architecture.md
+++ b/docs/source/getting-started/architecture.md
@@ -20,15 +20,15 @@ You can consider this file as the “flow orchestrator” of the benchmark. For
!!! note
- *For a more technical introduction to the benchmark configuration file, see the [corresponding page](https://hyperledger.github.io/caliper/v0.6.0/overview/bench-config/).*
+ *For a more technical introduction to the benchmark configuration file, see the [corresponding page](../concepts/bench-config.md).*
### Network configuration file
The content of the network configuration file is SUT-specific. The file usually describes the topology of the SUT, where its nodes are (their endpoint addresses), what identities/clients are present in the network, and what smart contracts Caliper should deploy or interact with.
For the exact structure of the network configuration files, refer to the corresponding SUT connector documentations (we will discuss connectors a bit later on this page):
-- [Hyperledger Besu & Ethereum](https://hyperledger.github.io/caliper/v0.6.0/connector-configuration/ethereum-config/)
-- [Hyperledger Fabric](https://hyperledger.github.io/caliper/v0.6.0/connector-configuration/fabric-config.md)
+- [Hyperledger Besu & Ethereum](../connectors/ethereum-config.md)
+- [Hyperledger Fabric](../connectors/fabric-config.md)
### Workload modules
@@ -38,14 +38,14 @@ Workload modules are simply Node.JS modules that must export a given factory fun
!!! note
- *For a more technical introduction to the benchmark configuration file, see the [corresponding page](https://hyperledger.github.io/caliper/v0.6.0/overview/workload-module/).*
+ *For a more technical introduction to the benchmark configuration file, see the [corresponding page](../concepts/workload-module.md).*
### Benchmark artifacts
There might be additional artifacts necessary to run a benchmark that can vary between different benchmarks and runs. These usually include the followings:
- Crypto materials necessary to interact with the SUT.
- Smart contract source code for Caliper to deploy (if the SUT connector supports such operation).
-- [Runtime configuration](https://hyperledger.github.io/caliper/v0.6.0/reference/runtime-config/) files.
+- [Runtime configuration](../concepts/runtime-config.md) files.
- Pre-installed third party packages for your workload modules.
Refer to the SUT connector configuration pages for the additional necessary artifacts.
@@ -61,7 +61,7 @@ A SUT connector provides a simplified interface towards internal Caliper modules
!!! note
- *For the technical details of how to implement a connector, refer to the [corresponding page](https://hyperledger.github.io/caliper/v0.6.0/reference/writing-connectors/).*
+ *For the technical details of how to implement a connector, refer to the [corresponding page](../connectors/writing-connectors.md).*
## Caliper processes
Caliper considers scalability one of its most important goals (besides extensibility/flexibility). Workload generation from a single machine can quickly reach the resource limitations of the machine. If we want the workload rate to match the scalability and performance characteristics of the evaluated SUT then we need a distributed approach!
@@ -94,9 +94,9 @@ The Caliper manager process is the orchestrator of the entire benchmark run. It
4. In the fourth stage Caliper schedules and executes the configured rounds through the worker processes. This is the stage where the workload generation happens (through the workers!).
5. In the last stage, after executing the rounds and generating the report, Caliper executes the cleanup script (if present) from the network configuration file. This step is mainly useful for local Caliper and SUT deployments as it provides a convenient way to tear down the network and any temporary artifacts.
-If your SUT is already deployed an initialized, then you only need Caliper to execute the rounds and nothing else. Luckily, you can configure every stage one-by-one whether it should be executed or not. See the [flow control settings](https://hyperledger.github.io/caliper/v0.6.0/reference/runtime-config/#benchmark-phase-settings) for details.
+If your SUT is already deployed an initialized, then you only need Caliper to execute the rounds and nothing else. Luckily, you can configure every stage one-by-one whether it should be executed or not. See the [flow control settings](../concepts/runtime-config.md#benchmark-phase-settings) for details.
-The above figure only shows the high-level steps of executing a benchmark. Some components are omitted for the sake of simplicity, like the resource and transaction monitor components. To learn more about the purpose and configuration of these components, refer to the [Resource and Transaction Monitors](https://hyperledger.github.io/caliper/v0.6.0/reference/caliper-monitors/) documentation page.
+The above figure only shows the high-level steps of executing a benchmark. Some components are omitted for the sake of simplicity, like the resource and transaction monitor components. To learn more about the purpose and configuration of these components, refer to the [Resource and Transaction Monitors](../concepts/caliper-monitors.md) documentation page.
### The worker process
The interesting things (from a user perspective) happen inside the worker processes. A worker process starts its noteworthy tasks when the manager process sends a message to it about executing the next round (the 4th step in the previous section). The important components of a worker process are shown in the figure below.
@@ -108,14 +108,14 @@ The worker process spends most of its time in the workload generation loop. The
1. Waiting for the rate controller to enable the next TX. Think of the rate controller as a delay circuit. Based on what kind of rate controller is used, it delays/halts the execution of the worker (in an asynchronous manner) before enabling the next TX. For example, if a fixed 50 TXs per second (TPS) rate is configured, the rate controller will halt for 20ms between each TX.
!!!note
- *The rate controllers of each round can be configured in the [benchmark configuration file](https://hyperledger.github.io/caliper/v0.6.0/overview/bench-config/). For the available rate controllers, see the [Rate Controllers](https://hyperledger.github.io/caliper/v0.6.0/reference/rate-controllers/) page.*
+ *The rate controllers of each round can be configured in the [benchmark configuration file](../concepts/bench-config.md). For the available rate controllers, see the [Rate Controllers](../concepts/rate-controllers.md) page.*
2. Once the rate controller enables the next TX, the worker gives control to the workload module. The workload module assembles the parameters of the TX (specific to the SUT and smart contract API) and calls the simple API of the SUT connector that will, in turn, send the TX request to the SUT (probably using the SDK of the SUT).
!!!note
- *The workload modules of each round can be configured in the [benchmark configuration file](https://hyperledger.github.io/caliper/v0.6.0/overview/bench-config/). For the technical details of workload modules, see the [Workload Modules](https://hyperledger.github.io/caliper/v0.6.0/reference/workload-module/) page.*
+ *The workload modules of each round can be configured in the [benchmark configuration file](../concepts/bench-config.md). For the technical details of workload modules, see the [Workload Modules](../concepts/workload-module.md) page.*
-During the workload loop, the worker process sends progress updates to the manager process. Progress reporting on the manager side can be enabled and configured with the `caliper-progress-reporting-enabled and caliper-progress-reporting-interval` setting keys. For details, see the [Basic Runtime Settings](https://hyperledger.github.io/caliper/v0.6.0/reference/runtime-config/#basic-settings).
+During the workload loop, the worker process sends progress updates to the manager process. Progress reporting on the manager side can be enabled and configured with the `caliper-progress-reporting-enabled and caliper-progress-reporting-interval` setting keys. For details, see the [Basic Runtime Settings](../concepts/runtime-config.md/#basic-settings).
## Process distribution models
The last part of the architecture discussion is demystifying the worker process management. Based on how worker processes are started and what messaging method is used between the manager and worker processes, we can distinguish the following distribution/deployment models:
@@ -150,10 +150,10 @@ The following table summarizes the different models and how to select them:
!!! note
- *For the technical details on configuration the messaging transport, see the [Messengers](https://hyperledger.github.io/caliper/v0.6.0/reference/caliper-messengers/) page.*
+ *For the technical details on configuration the messaging transport, see the [Messengers](../concepts//caliper-messengers.md) page.*
### Interprocess communication
-The examples on the [Install & Usage](https://hyperledger.github.io/caliper/v0.6.0/overview/installing-caliper/) page all use the IPC approach since it is the default behavior. The setup is illustrated in the figure below.
+The examples on the [Install & Usage](../getting-started/installing-caliper.md) page all use the IPC approach since it is the default behavior. The setup is illustrated in the figure below.
The `caliper launch manager` CLI command starts the manager process, which in turn will automatically spawn the configured number of worker processes (using the `caliper launch worker` CLI command). The communication between the processes is IPC, utilizing the built-in Node.JS method available for the parent-children process relationships.
@@ -177,7 +177,7 @@ When you take the management of the worker processes into your own hands, that
-The fully distributed deployment enables the horizontal scaling of the worker processes, greatly increasing the achievable workload rate. To ease the management of the many Caliper processes, you will probably utilize some automatic deployment/management solution, like Docker Swarm or Kubernetes. Luckily, the flexibility of the [Caliper Docker image](https://hyperledger.github.io/caliper/v0.6.0/overview/installing-caliper/#using-the-docker-image) makes such integration painless.
+The fully distributed deployment enables the horizontal scaling of the worker processes, greatly increasing the achievable workload rate. To ease the management of the many Caliper processes, you will probably utilize some automatic deployment/management solution, like Docker Swarm or Kubernetes. Luckily, the flexibility of the [Caliper Docker image](../getting-started/installing-caliper.md#using-the-docker-image) makes such integration painless.
However, there are some caveats you have to keep in mind:
@@ -187,4 +187,4 @@ However, there are some caveats you have to keep in mind:
## License
-The Caliper codebase is released under the [Apache 2.0 license](https://hyperledger.github.io/caliper/v0.6.0/general/license/). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
+The Caliper codebase is released under the [Apache 2.0 license](../getting-started/license.md). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
diff --git a/docs/source/getting-started/contributing.md b/docs/source/getting-started/contributing.md
index 69d1e16bb..1f69be87b 100644
--- a/docs/source/getting-started/contributing.md
+++ b/docs/source/getting-started/contributing.md
@@ -135,10 +135,10 @@ The project is maintained as a Node.js monorepository. Accordingly, it can seem
The workflow of modifying the Caliper code-base usually consists of the following steps:
-1. [Bootstrapping the repository](https://hyperledger.github.io/caliper/v0.6.0/getting-started/contributing/#bootstrapping-the-caliper-repository)
-2. [Modifying and testing the code](https://hyperledger.github.io/caliper/v0.6.0/getting-started/contributing/#testing-the-code)
-3. [Publishing package changes locally](https://hyperledger.github.io/caliper/v0.6.0/getting-started/contributing/#publishing-to-local-npm-repository)
-4. [Building the Docker image](https://hyperledger.github.io/caliper/v0.6.0/getting-started/contributing/#building-the-docker-image)
+1. [Bootstrapping the repository](#bootstrapping-the-caliper-repository)
+2. [Modifying and testing the code](#testing-the-code)
+3. [Publishing package changes locally](#publishing-to-local-npm-repository)
+4. [Building the Docker image](#building-the-docker-image)
### Bootstrapping the Caliper repository
@@ -253,7 +253,7 @@ user@ubuntu:~/caliper$ node ./packages/caliper-cli/caliper.js launch manager \
Connectors are relatively heavy components in Caliper. Before you attempt to create a new connector for a new SUT type, consult with the Caliper maintainers (on Discord, or in the form of a feature request).
-> More importantly, make sure that you are overly familiar with the documentation page about [implementing new connectors](https://hyperledger.github.io/caliper/v0.6.0/connectors/writing-connectors/).
+> More importantly, make sure that you are overly familiar with the documentation page about [implementing new connectors](../connectors/writing-connectors.md).
### Publishing to local NPM repository
diff --git a/docs/source/getting-started/faq.md b/docs/source/getting-started/faq.md
index beb0628c4..57f30d107 100644
--- a/docs/source/getting-started/faq.md
+++ b/docs/source/getting-started/faq.md
@@ -3,7 +3,7 @@
## **I. Environment, Platform & Version**
**Q:** How do I run Caliper to test a blockchain system?
-**A:** Details for setting up Caliper to run benchmark tests on a blockchain system are provided in the [Getting Started](https://hyperledger.github.io/caliper/v0.6.0/overview/getting-started/) page of the site. When you run Caliper to test a blockchain network, you may encounter some errors. If so, first you should check the version of tools, SDKs and modules to make sure it is right.
+**A:** Details for setting up Caliper to run benchmark tests on a blockchain system are provided in the [Getting Started](../index.md) page of the site. When you run Caliper to test a blockchain network, you may encounter some errors. If so, first you should check the version of tools, SDKs and modules to make sure it is right.
## **II. Configuration Files of Caliper**
@@ -18,7 +18,7 @@ There is another configuration file, namely `./config/default.yaml`, containing
**A:** Now you can use Caliper to test Besu, Ethereum and Fabric.
**Q:** How can I test a blockchain system that Caliper does not support currently？
-**A:** If you want to test the blockchain system that Caliper does not support now, you must write your own blockchain adapter that Caliper can use to inferface with the backend network. For details, you can refer to the [Writing Adapters](https://hyperledger.github.io/caliper/v0.6.0/caliper-faq/reference/writing-connectors/) page. The Caliper-specific configurations remain unchanged. Take a look at the provided adapter implementations and example networks to gather some best-practices.
+**A:** If you want to test the blockchain system that Caliper does not support now, you must write your own blockchain adapter that Caliper can use to inferface with the backend network. For details, you can refer to the [Writing Adapters](../connectors/writing-connectors.md) page. The Caliper-specific configurations remain unchanged. Take a look at the provided adapter implementations and example networks to gather some best-practices.
## **IV. Other Questions Related to Caliper**
diff --git a/docs/source/getting-started/installing-caliper.md b/docs/source/getting-started/installing-caliper.md
index d816af0d3..d82bd6375 100644
--- a/docs/source/getting-started/installing-caliper.md
+++ b/docs/source/getting-started/installing-caliper.md
@@ -2,7 +2,7 @@
## Overview
-Caliper is published as the [@hyperledger/caliper-cli](https://www.npmjs.com/package/@hyperledger/caliper-cli) NPM package and the [hyperledger/caliper](https://hub.docker.com/r/hyperledger/caliper) Docker image, both containing the CLI binary. Refer to the [Installing from NPM](https://hyperledger.github.io/caliper/v0.6.0/overview/installing-caliper/#installing-from-npm) and [Using the Docker image](https://hyperledger.github.io/caliper/v0.6.0/overview/installing-caliper/#using-the-docker-image) sections for the available versions and their intricacies.
+Caliper is published as the [@hyperledger/caliper-cli](https://www.npmjs.com/package/@hyperledger/caliper-cli) NPM package and the [hyperledger/caliper](https://hub.docker.com/r/hyperledger/caliper) Docker image, both containing the CLI binary. Refer to the [Installing from NPM](#installing-from-npm) and [Using the Docker image](#using-the-docker-image) sections for the available versions and their intricacies.
Installing and running Caliper consists of the following steps, thoroughly detailed by the remaining sections:
@@ -34,7 +34,7 @@ Unless you are embedding the Caliper packages in your own application, you will
!!! note
- *The following examples assume a locally installed CLI in the `~/caliper-benchmarks` directory, hence the `npx` call before the `caliper` binary. Refer to the [Local NPM install](https://hyperledger.github.io/caliper/v0.6.0/overview/installing-caliper/#local-npm-install) section for the specifics.*
+ *The following examples assume a locally installed CLI in the `~/caliper-benchmarks` directory, hence the `npx` call before the `caliper` binary. Refer to the [Local NPM install](#local-npm-install) section for the specifics.*
The entry point of the CLI is the `caliper` binary. You can confirm whether the CLI is installed correctly by checking its version:
@@ -71,7 +71,7 @@ You can also request the help page of a specific command, as demonstrated by the
!!! note
- *the command options can be set either through the command line, or from various other sources supported by the [configuration mechanism](https://hyperledger.github.io/caliper/v0.6.0/reference/runtime-config/) of Caliper. This flexibility makes it easy to embed the CLI in different environments.*
+ *the command options can be set either through the command line, or from various other sources supported by the [configuration mechanism](../concepts/runtime-config.md) of Caliper. This flexibility makes it easy to embed the CLI in different environments.*
### The bind command
@@ -110,7 +110,7 @@ The following SUT name and SDK version combinations are supported:
The `bind` command is useful when you plan to run multiple benchmarks against the same SUT version. Bind once, then run different benchmarks without the need to bind again. As you will see in the next sections, the launcher commands for the manager and worker processes can also perform the binding step if the required parameter is present.
#### Custom bindings
-The built-in bindings can be overridden by setting the `caliper-bind-file` parameter to a YAML file path. The file must match the structure of the [default binding file](https://github.com/hyperledger/caliper/blob/main/packages/caliper-cli/lib/lib/config.yaml), documented [here](https://hyperledger.github.io/caliper/v0.6.0/reference/writing-connectors#binding-configuration). This way you can use experimental SDK versions that are not (yet) officially supported by Caliper. **This also means that we cannot provide help for such SDK versions!**
+The built-in bindings can be overridden by setting the `caliper-bind-file` parameter to a YAML file path. The file must match the structure of the [default binding file](https://github.com/hyperledger/caliper/blob/main/packages/caliper-cli/lib/lib/config.yaml), documented [here](../connectors/writing-connectors.md#binding-configuration). This way you can use experimental SDK versions that are not (yet) officially supported by Caliper. **This also means that we cannot provide help for such SDK versions!**
### The unbind command
@@ -205,7 +205,7 @@ Options:
As you can see, you can configure the worker processes the same way as the manager process. Including the optional binding step, but also the three mandatory parameters mentioned in the previous section.
#### Caliper test phase control
-Caliper commands are capable of passing all [runtime configuration settings](https://hyperledger.github.io/caliper/v0.6.0/reference/runtime-config/). A subset of these commands are for flow control that provide direct control over the following Caliper phases:
+Caliper commands are capable of passing all [runtime configuration settings](../concepts/runtime-config.md). A subset of these commands are for flow control that provide direct control over the following Caliper phases:
- start
- init
@@ -345,7 +345,7 @@ Parts of starting a Caliper container (following the recommendations above):
!!! note
- *the **latest** tag is **not supported**, i.e, you explicitly have to specify the image version you want: hyperledger/caliper:0.6.0, similar to the recommended approach for the [NPM packages](https://hyperledger.github.io/caliper/v0.6.0/overview/installing-caliper/#versioning-semantics).*
+ *the **latest** tag is **not supported**, i.e, you explicitly have to specify the image version you want: hyperledger/caliper:0.6.0, similar to the recommended approach for the [NPM packages](#versioning-semantics).*
Putting it all together, split into multiple lines for clarity, and naming the container `caliper`:
@@ -390,4 +390,4 @@ docker-compose up
## License
-The Caliper codebase is released under the [Apache 2.0 license](https://hyperledger.github.io/caliper/v0.6.0/general/license/). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
+The Caliper codebase is released under the [Apache 2.0 license](../getting-started/license.md). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
diff --git a/docs/source/index.md b/docs/source/index.md
index 016236bb9..1e2253b0c 100644
--- a/docs/source/index.md
+++ b/docs/source/index.md
@@ -37,8 +37,8 @@ Performance reports for the provided samples are hosted on the [documentation pa
*make sure that the version/tag of the benchmark repository matches the version of Caliper you are using! For example, if you are using Caliper v0.6.0, then `checkout` the `v0.6.0` tag after cloning the benchmark repository. The `main` branch of the benchmark repository corresponds to the latest `unstable` Caliper version.*
## How to Contribute
-Every contribution is welcome! See the [Contributing](https://hyperledger.github.io/caliper/v0.6.0/contributing/) page for details.
+Every contribution is welcome! See the [Contributing](getting-started/contributing.md) page for details.
## License
-The Caliper codebase is released under the [Apache 2.0 license](https://hyperledger.github.io/caliper/v0.6.0/license/). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
+The Caliper codebase is released under the [Apache 2.0 license](getting-started/license.md). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
diff --git a/docs/source/tutorial/fabric.md b/docs/source/tutorial/fabric.md
index c11dde223..4d44ce279 100644
--- a/docs/source/tutorial/fabric.md
+++ b/docs/source/tutorial/fabric.md
@@ -515,4 +515,4 @@ You have successfully benchmarked a smart contract. You can repeat the test vary
## License
-The Caliper codebase is released under the [Apache 2.0 license](https://hyperledger.github.io/caliper/v0.6.0/general/license/). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file
+The Caliper codebase is released under the [Apache 2.0 license](../getting-started/license.md). Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/).
\ No newline at end of file