Merge pull request #98 from zigbee-alliance/load-test-design-update

Docs update

Author: ashcherbakov

README.md

@@ -51,7 +51,7 @@ In order to send write transactions to the ledger you need:
       - Sign every transaction by the private key.
  - PoA (proof of authority) approach is used for adding new validator nodes to the network 
  (see [Add New Node Use Case](docs/use_cases/use_cases_add_validator_node.png)) and
-  [Running Node Instructions](docs/running-node.md).
+  [Running Node Instructions](docs/running-validator-node.md).
 
 
 
@@ -126,15 +126,20 @@ One can either deploy its own network of validator nodes or join one of the pers
 - If you want to deploy your own network for debug purposes,
 you can use the provided Ansible Playbook: [ansible/readme.md](deployment/ansible/README.md).
 - If you want to join an existing network (either a custom or persistent) as a validator node,
-please follow the [Running a Validator Node](docs/running-node.md) instructions.
+please follow the [Running a Validator Node](docs/running-validator-node.md) instructions.
 - If you want to deploy your own persistent network,
 you will need to create a genesis node and a genesis file first as described in [Running a Genesis Validator Node](docs/running-genesis-node.md).
-After this more nodes can be added by following the [Running a Validator Node](docs/running-node.md) instructions.
+After this more nodes can be added by following the [Running a Validator Node](docs/running-validator-node.md) instructions.
 Please note, that [Running a Genesis Validator Node](docs/running-genesis-node.md) describes 
 the case when the genesis block consist of a single node only. This is done just for simplicity, 
 and nothing prevents you from adding more nodes to the genesis file by adapting the instructions accordingly. 
+- If you want to join an existing network  as an observer node,
+please follow the [Running an Observer Node](docs/running-observer-node.md) instructions.
+
+A recommended way for deployment and client connection: [diagram](docs/deployment.png)
 
 ## Useful Links 
+- [Quick Start](docs/quickStartGuide.adoc)
 - [Use Case Diagrams](docs/use_cases)
     - [PKI](docs/use_cases/use_cases_pki.png)
     - [Device on-ledger certification](docs/use_cases/use_cases_device_on_ledger_certification.png)
@@ -148,7 +153,9 @@ and nothing prevents you from adding more nodes to the genesis file by adapting
 - [CLI Help](docs/cli-help.md)
 - [Deployment](deployment/ansible/README.md)
 - [Running a Genesis Validator Node](docs/running-genesis-node.md)
-- [Running a Validator Node](docs/running-node.md)
+- [Running a Validator Node](docs/running-validator-node.md)
+- [Running an Observer Node](docs/running-observer-node.md)
+- [Deployment Pattern](docs/deployment.png)
 - [Tendermint](https://tendermint.com/)
 - [Cosmos SDK](https://cosmos.network/sdk)
 

docs/deployment.png

@@ -1,11 +1,25 @@
 # Benchmarking
 
+## Test Phases
+
+1. Phase 1 (MVP)
+   - the main goal is to understand general limitations and get metrics for the core protocol 
+   - just one txn type 
+   - dedicated, but simple environment (simple deployment of validators similar to the current Test Net; no observers, no sentry nodes, no mediators)
+
+2. Phase 2
+   - the main goal is to test DCL specific (DCL business logic and txn types; deployment specific)  
+   - more txn types  
+   - more workload scenarios 
+   - simulate deployment as close to production as possible
+
+
 ## Client Side Metrics
 
 *   `response time` (percentiles): the time between client's initial request and the last byte of a validator response
 *   `requests per second (RPS)`: number of requests per second
-    *   `transactions per second (TPS)`: number of write requests (txns) per second
-        *   **Note** to measure that on client side write requests should use to `broadcast_tx_commit` requetss
+*   `transactions per second (TPS)`: number of write requests (txns) per second
+    *   **Note** to measure that on client side write requests should use to `broadcast_tx_commit` requetss
 *   `number of clients`: number of concurrent clients that ledger serves
 *   (optional) `throughtput` (in/out): number of KB per second. Marked as optional since we don't expect much in/out data due to relatively small txns payloads.
 
@@ -44,21 +58,23 @@ The following [metrics](https://docs.cosmos.network/master/core/telemetry.html#s
 
 Options:
 
-*   dedicated, close to production as much as possible (the best option)
-*   local in-docker (for PoC / debugging only)
-*   TestNet, not good: not a clean environment, would be spammed and might be broken by the load testing
+* dedicated, close to production as much as possible (the best option)
+* dedicated, simple deployment of validators similar to the current Test Net (no observers, no sentry nodes, no mediators);
+  good for initial test phase 
+* local in-docker (for PoC / debugging only)
+* TestNet, not good: not a clean environment, would be spammed and might be broken by the load testing
 
 Notes:
 
 *   For the moment it's not clear enough what production setup will look like, in particular:
-    *   number of vendor companies (number of validators)
+    *   number of validators
     *   type of external endpoints, options are [Cosmos SDK / Tendermint endpoints](https://docs.cosmos.network/master/core/grpc_rest.html)
     *   type and number of proxies for validator-validator and client-validator connections
 
-Current assumptions:
+Current assumptions for production:
 
-*   multiple companies (vendors) will manage one/multiple validators
-*   while some common requirements and recommendations would be provided each vendor will deploy the infrastructure independently with some freedom regarding internal architecture
+*   multiple companies will manage one/multiple validators
+*   while some common requirements and recommendations would be provided each company will deploy the infrastructure independently with some freedom regarding internal architecture
 *   there would be a set of external (for clients) and internal (for validators to support txn flows) endpoints
     *   most likely observer nodes along with REST http servers with clients authentication would be in front of the client endpoints
 

docs/design/benchmarking.md

@@ -1,4 +1,4 @@
-## Running a Observer Node
+## Running an Observer Node
 
 This document describes in details how to run a observer node, and add it to the existing network.
 
@@ -79,15 +79,18 @@ and contains the genesis and persistent_peers files.
 
 
 4. Start the local observer node
-   * Init Node: `dcld start`.
+   * Enable the service: `sudo systemctl enable dcld`
+   * Start node: `sudo systemctl start dcld`
+   * For testing purpose the node can be started in CLI mode: `dcld start` (instead of two previous `systemctl` commands).
+   Service mode is recommended for demo and production environment.
+
    You should see it trying to get all the blocks from the testnet. (p.s. It can take upto 12+ hrs for all the transactions to be downloaded depending on network speed)
 
 
-5. Check the observer node is running and getting all the transcations:
+5. Check the observer node is running and getting all the transactions:
 
-    * Get the node status: `dclcli status --node localhost:26657`. 
-     
-    Make sure that `result.sync_info.latest_block_height` is increasing over the time (once in about 5 sec). When you see the `catching_up` as `true` that signifies that the node is still downloading all the transactions. Once it has fully synced this will value will turn to `false`
+    * Get the node status: `dclcli status --node localhost:26657`.
+    * Make sure that `result.sync_info.latest_block_height` is increasing over the time (once in about 5 sec). When you see the `catching_up` as `true` that signifies that the node is still downloading all the transactions. Once it has fully synced this will value will turn to `false`
        Expected output format: 
         ```json
                     {
@@ -126,4 +129,4 @@ and contains the genesis and persistent_peers files.
             }
         ```
 
-6. Congrats! You are an now running a observer node.
+6. Congrats! You are now running an observer node.