Skip to content

Commit

Permalink
Create network_performance.rst
Browse files Browse the repository at this point in the history
  • Loading branch information
svyatmikh committed Jun 6, 2019
1 parent f829af9 commit 67fa5e8
Showing 1 changed file with 60 additions and 0 deletions.
60 changes: 60 additions & 0 deletions doc/network_performance.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
Network Performance
===================

Papyrus network designed as high loaded solution that should be able to process more than 1000 tps.
To achieve these performance results we completely changed most of ethereum transaction constants.

Results of this tuning you may see below:

* A ``tx_pool.go`` class that contains most of logic for the transaction pool:

.. container:: codeset

.. sourcecode:: before

const (
// chainHeadChanSize is the size of channel listening to ChainHeadEvent.
chainHeadChanSize = 10
)

.. sourcecode:: after

const (
// chainHeadChanSize is the size of channel listening to ChainHeadEvent.
chainHeadChanSize = 10
)


After that we added transaction batching.
This kind of transaction packaging lets us to drastically increase network performance without compromising security.
In order to unlock the full potential of this approach, we also had to rework the queue sizes for pending and queued transactions.
While these changes implied new changes in parameters of the maximum number of permissible transactions, and, most importantly,
in the total number of transactions.

Finally, we overhauled buffers.

The result is a tenfold increase in performance. For multiple tests, we used a specific utility to load the network with 1500 transactions every second.
The test results showed that the network successfully handles 1500 transactions per second and works stably at such a load for a long period of time.
Below you can find the logs of the utility and the logs of the node.
The logs show that all 1500 transactions fall into a block, which is generated every second. During the test, we used the type of configuration, suggesting the entire load to be applied to one gateway node, while the gateway-node is not engaged in the generation of blocks.
Blocks are generated by several sealer nodes.

Results



Utility logs:

.. image:: images/utility_logs.jpg

Node logs:

.. image:: images/node_logs.jpg

A visual representation, which can be seen on our monitor explorer (screenshot):

.. image:: images/explorer_logs.jpg

The test shows, that 1500 transactions fall into a block every second it is generated.

As a result, we got the desired and unique combination of a quality network.

0 comments on commit 67fa5e8

Please sign in to comment.