You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Last year we were able to measure a TPS in the 1000-2000 range. Recently during performance testing we had maximum of 150. This turned out to be a configuration problem. However, hiding behind this configuration issue were several issue that inhibit a higher TPS iroha network.
The first was some kind of issue with transactions that were close to expiration. I was able to solve this with some padding added to the expiration code to remove these "risky" transactions while in the queue. This is however not the solution we are moving forward with. Instead a coordinated time between the nodes is being considered.
The second was simply the configuration of block size. With a low block size the network cannot have high throughput because of the ping time between nodes. The road to higher TPS numbers lies in bigger and bigger block sizes. However, eventually there is a stability problem when blocks are too big and take too long to process. The dev team are currently discussion potential changes to how the consensus works in order to reduce these instability issues. There will always be a limit on block size. But ideally a too big number should just result in slow block production instead of no block production which it can do as of now.
The third issue is block sync. Block sync as is currently implemented has several flaws where it can both be too slow or pull in too much redundant data from other nodes. In the former case the node is simply behind and never catches up to the other nodes unless block production slows down. In the latter what occurs is a kind of "self-denial of service" where it requests the same blocks over and over again causing the node to become inoperable. This third issue is the highest priority in my opinion and is something I intend to work on soon.
The text was updated successfully, but these errors were encountered:
Last year we were able to measure a TPS in the 1000-2000 range. Recently during performance testing we had maximum of 150. This turned out to be a configuration problem. However, hiding behind this configuration issue were several issue that inhibit a higher TPS iroha network.
The first was some kind of issue with transactions that were close to expiration. I was able to solve this with some padding added to the expiration code to remove these "risky" transactions while in the queue. This is however not the solution we are moving forward with. Instead a coordinated time between the nodes is being considered.
The second was simply the configuration of block size. With a low block size the network cannot have high throughput because of the ping time between nodes. The road to higher TPS numbers lies in bigger and bigger block sizes. However, eventually there is a stability problem when blocks are too big and take too long to process. The dev team are currently discussion potential changes to how the consensus works in order to reduce these instability issues. There will always be a limit on block size. But ideally a too big number should just result in slow block production instead of no block production which it can do as of now.
The third issue is block sync. Block sync as is currently implemented has several flaws where it can both be too slow or pull in too much redundant data from other nodes. In the former case the node is simply behind and never catches up to the other nodes unless block production slows down. In the latter what occurs is a kind of "self-denial of service" where it requests the same blocks over and over again causing the node to become inoperable. This third issue is the highest priority in my opinion and is something I intend to work on soon.
The text was updated successfully, but these errors were encountered: