# TPS in a Substrate-based blockchain

For developers today's blockchain space looks abundant in possibilities. One can choose between different options: build something on Bitcoin or Ethereum, or try more centralized solutions like EOS or TRON, or maybe look in the direction of a new wave of blockchains such as Algorand or Solana. In any case, for a popularizable application, an important factor in choosing is the blockchain throughput, i.e. the number of transactions per second that can be recorded and finalized.

Blockchain based on the Substrate is a good choice among other blockchains due to its ease of launch and configuration flexibility. But I very rarely saw any official information about the bandwidth of a Substrate blockchain, and in most cases it came down to the future Polkadot/Kusama bandwidth, where it was clear from the context that this was not the bandwidth of one chain, but the bandwidth of the entire network consisting of parallel parachains/parathreds connected to the relay chain.
So how many transactions can an out of the box (almost unchanged) substrate network process per second?

One of the basic rules of the blockchain space is: don’t trust, verify. Therefore, we decided to test it ourselves.

We wrote a code that simulates a large number of users (further clients) doing some activities on the network. The task of each of the clients was quite simple
1) connecting to a specific node;
2) creating a random address for the recipient;
3) sending transactions to the recipient address sequentially.

After sending each transaction, the client waited til the moment this transaction was finalized, and only after that was sending the next transaction, and so on until the client is stopped. Clients were launched in packages, but worked in parallel and independently of each other. Each of the clients reserved a separate connection to the network and during the test has been sending transactions through a single connection channel.

For our experiment, we used the this [commit](https://github.com/paritytech/substrate/commit/de2ffd937db78093efaa58d7cc08f5599a8f4728) from February 2, 2020, and a network based on the node-template in this repository.
For the experiment, we had to change the MaximumBlockWeight and MaximumBlockLength values to the maximal u32 values (by default, the values were 1,000,000 and 5 * 1024 * 1024, respectively).

We started our experiment with dev chain (the network runs on one computer), and while sending transactions simultaneously from 500 addresses, we managed to reach the processing of 401 transactions in a block, whereas the average number of transactions in a block, when they remained in the queue during the experiment, was 314.
Thus, with a standard 6 seconds interval between the blocks, we got a peak value of about 67 tps, and an average value of about 52 tps.


A dev network has many differences from how the network functions under real conditions.
A step towards the reality implied creating a network of 4 nodes (8 CPUs, 32 GB RAM), that were located in one data center, and repeating the experiment. This time the peak value reached 213 transactions, and the average value was 199 transactions.
Thus, in the peak value, the number of tps for the standard network was 36, and the average value was about 33.


I would like to note that the network behaved very stably, the nodes continued to function normally under loads, none of them crashed and only rarely the block creation was delayed slightly, the mechanisms of Babe and Grandpa worked without any problems, the greatest average time between blocks was 6.4s, and the maximum delay in finalizing transactions was 5 blocks.

Unfortunately, we still do not know where is the bottleneck for bandwidth, since cpu usage and memory usage did not exceed 60% on any of the nodes, and the presence of transactions in the node queue indicates that the spreading of the transactions on the network wasn’t a problem either. At the moment, my assumption is that the process of adding transactions to the block might not be sufficiently parallelized, although additional tests are needed to fully understand the situation (if you have any clue, we would be happy to hear it!).

Our code is available [here](https://github.com/gitigs/substrate-tps-test).
You can check the experiment data on [our network](https://telemetry.polkadot.io/#list/cw_test).
Blocks associated to the experiment: 331600-333100