-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
60 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |