6.8.3 Network Performance

The performance of distributed systems differs significantly from regular IT systems and depends on many factors:

- The performance of the hardware that the node is running on.

- The speed of the network hardware to which the nodes are connected.

- Network volume (number of nodes), in case of distributing transactions over several nodes, the network may show greater performance than with one node.

- The consensus mechanism used – the security and integrity of the ledger is ensured by complex mechanisms (voting, such as in F-BT; mining, such as in PoW of Bitcoin, Ethereum).

- Cryptography mechanisms that require additional computational procedures, possibly with GPU support.

- Transactions to be executed (transactions that require significant processing may be much slower). Moreover, transactions that perform reading from a distributed ledger and transactions that provide writing (directly passing through the consensus procedure) have a significant difference.

- Performance of the client software used to perform transactions, as well as its distributed nature and architecture.

These factors make it much more difficult to compare different systems with each other and render such indicators as absolute number of transactions per second as meaningless. Key performance metrics include:

- Read Latency = [Time when response received – submit time] (time between sending a read request and receiving a response)

- Read Throughput = [Total read operations / Total time in seconds] (throughput expressed in number of reads per unit of time)

- Transaction Latency = [Confirmation Time| Network Threshold – Submit Time] (time between confirmation at the network threshold and sending the transaction). Since blockchain networks are asynchronous in nature, the response (check) to the transaction comes immediately, and confirmation that the transaction has been accepted and added to the corresponding block requires consensus time.

- Transaction Throughput = [Total committed transactions/total time in second on committed nodes] (throughout of transactions, speed of acceptance and distribution of transactions throughout the blockchain). This speed is measured in TPS, the number of transactions per second.

When conducting test measurements, it is recommended to plan and record the performance test plan:

#	Parameter		Description
1	Name of the test		Arbitrary short test name
2	Planned or actual testing start and end dates		The timing of testing allows you to evaluate the duration of tests and the time between failures
3			The testing objective informs its strategy ahead of time
4	DGT version		Record the version that you tested
5	Transaction family		Different transaction systems have varying load
6	Network model		Record the topology used, including the number of nodes and their distribution across clusters
7	Geographic distribution of nodes		Nodes that are located remotely bring additional costs and network effects to the network
8	Test script		The number of transactions, series, workload, and observed points (nodes)
9	Test toolkit

Throughout the testing process, keep an accurate protocol in which, for each scenario, you record the collected metrics, successful and unsuccessful runs, errors, and other information.

The main recommendations for choosing the tools and testing method are as follows:

- Preference should be given to instruments that can interact with the API. JMeter or Postman are recommended as such tools.

- Run a series of tests measuring Latency and Throughput. Use averaging functions for measured metrics.

- Save automated tests and attach them to test protocols.

- When making comparisons, be guided by well-known testing frameworks for distributed systems (for example, Hyperledger Caliper)

Figure 156 Postman Scripting