<commit_before># Introduction

In the new major version of Mongoose the new distributed mode architecture is introduced. Any *distributed load step*
execution may be initiated from any node from the given set. Then the chosen node becomes an temparary *entry node*.
There may be also *additional nodes* involved in the given distributed load step. All necessary input is prepared
(*sliced*) and distributed among the nodes before the actual load step start to get rid of the redundant interaction
via the network during the load step execution. The additional nodes are being polled periodically to synchronize the
load step state. After the load step is done, the summary data may be (optionally) aggregated and persisted on the entry
node.

| v3.x.x | v4.x.x
|----|----
| ![Distributed Mode v3.x.x](../images/distributed_mode_v3.png) | ![Distributed Mode v4.x.x](../images/distributed_mode_v4.png)

* **v3.x.x**
    * The "controller" is used to initiate the run
    * The "controller" is located at separate host usually
    * The "drivers" are "thin": execute the I/O tasks only (in other words, contains storage driver only)
    * The "controller" is "rich"
* **v4.x.x**
    * The *entry node* is used to initiate the run
    * Any node may be used to initiate the run
    * The *additional node* is functionally "rich": it executes the load step "slices" entirely and independently (in
      other words, contains storage driver, load generator, load step service, etc)

## Advantages

1. Higher distributed mode performance due to lack of the single point of contention
2. The opportunity to introduce the modular configuration
3. Joint interface for CLI and GUI

# Design

The distributed mode test involves at least one entry node and some set of the additional nodes. The test may be started
from any node from that set. The node selected to start the test should be temporarily treated as the *entry node*.
The entry node is not excluded from the actual load execution.

## Entry Node

Entry node loads the scenario into the corresponding scripting engine. The scripting engine instantiates the scenario
steps. Each load step consists of its local and remote parts. The local step functionality:

* step slicing
* load the input items and distribute to the nodes
* item output file aggregation (optional)
* I/O traces aggregation (optional)

### Scenario Step Slicing

The configuration parameters which are the subject of slicing in the scenario:<commit_msg>save [skip ci]<commit_after># Introduction

In the new major version of Mongoose the new distributed mode architecture is introduced. Any *distributed load step*
execution may be initiated from any node from the given set. Then the chosen node becomes an temparary *entry node*.
There may be also *additional nodes* involved in the given distributed load step. All necessary input is prepared
(*sliced*) and distributed among the nodes before the actual load step start to get rid of the redundant interaction
via the network during the load step execution. The additional nodes are being polled periodically to synchronize the
load step state. After the load step is done, the summary data may be (optionally) aggregated and persisted on the entry
node.

| v3.x.x | v4.x.x
|----|----
| ![Distributed Mode v3.x.x](../images/distributed_mode_v3.png) | ![Distributed Mode v4.x.x](../images/distributed_mode_v4.png)

* **v3.x.x**
    * The "controller" is used to initiate the run
    * The "controller" is located at separate host usually
    * The "drivers" are "thin": execute the I/O tasks only (in other words, contains storage driver only)
    * The "controller" is "rich"
* **v4.x.x**
    * The *entry node* is used to initiate the run
    * Any node may be used to initiate the run
    * The *additional node* is functionally "rich": it executes the load step "slices" entirely and independently (in
      other words, contains storage driver, load generator, load step service, etc)

## Advantages

1. Higher distributed mode performance due to lack of the single point of contention
2. The opportunity to introduce the modular configuration
3. Joint interface for CLI and GUI

# Design

## Requirements

## Assumptions

## Limitations

The distributed mode test involves at least one entry node and some set of the additional nodes. The test may be started
from any node from that set. The node selected to start the test should be temporarily treated as the *entry node*.
The entry node is not excluded from the actual load execution.

## Entry Node

Entry node loads the scenario into the corresponding scripting engine. The scripting engine instantiates the scenario
steps. Each load step consists of its local and remote parts. The local step functionality:

* step slicing
* load the input items and distribute to the nodes
* item output file aggregation (optional)
* I/O traces aggregation (optional)

### Scenario Step Slicing

The configuration parameters which are the subject of slicing in the scenario:
{'fraction_non_alphanumeric': 0.06172344689378757, 'fraction_numerical': 0.004408817635270541, 'mean_word_length': 4.166666666666667, 'pattern_counts': {'":': 4, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4202977', 'n_tokens_mistral': 1286, 'n_tokens_neox': 1225, 'n_words': 726}