Skip to main content

Nxt Blockchain - Loadtest Results

15 May 2017

Here are the results from a blockchain workshop conducted on May 15th, 2017. Test was performed using a modified version of an Nxt 1.11.5 private blockchain instance. During the test, 3 million sendMoney transactions were submitted to the blockchain by a load testing tool, while the nodes behavior and performance were carefully inspected and profiled.

Test results and observations are listed below:

Hardware

  • Node #1 - Asus N752VX 16GB RAM 256GB SSD Windows 10 64 bit
  • Node #2 - Dell Latitude E5550 16GB RAM 512GB SSD Windows 7 64 bit
  • Network - 1 Gigabit Ethernet

Software

  • Nxt 1.11.5 with modifications running as private blockchain
  • Java 1.8.0_131
  • JMeter 3.1 loader utility

Test Configuration

  • Two forging nodes each funded with 100M NXT
  • sendMoney transactions
  • 3 Million confirmed transactions over a time period of over 8 hours
  • Block time of 1 minute
  • The existing 256 Transactions per Block limit has been removed

Node Configuration

  • nxt.peerReconnectDelay=0
  • nxt.peerUpdateDelay=0
  • nxt.maxNumberOfTransactions=72000
  • nxt.maxUnconfirmedTransactions=72000
  • nxt.peerServerDoSFilter.maxRequestsPerSec=3000
  • nxt.wellKnownPeers=<node1>;<node2>

Results

  • Sustainable throughput of 100 TPS (Transactions per Second)
  • CPU utilization average of 30%
  • Memory consumption of 3 GB

Observations

  • Unlike the blockchain used by the loadtest, the current production public blockchain is practically limited to around 12 TPS on top of the 256 transactions per block artificial limit which further limits its throughput to around 4 TPS. At the moment higher throughput is not needed, however, it can be provided relatively quickly.
  • Scaling the blockchain to 100 TPS required complex optimizations. These optimizations won’t be released under the GPLv2 license. They will be available only for commercial private blockchain projects or blockchains running under the JPL license.
  • For a single workstation forging independently, maximum performance was 280 TPS.
  • For the dual node test, the main limiting factor was fork resolution, switching to a better fork is a resource intensive operation - we should see improvement in this respect in Ardor due to more efficient peer networking.
  • Workstation CPU and Memory were not maxed out by this test, from this we conclude that:
    • I/O and mainly database performance is the limiting factor
    • SSD drive is a must have for a high performance node
    • Hardware with slower CPU and less RAM should still achieve similar results
  • More specifically, the H2 database, currently used by Nxt, represents a possible bottleneck. We are looking into replacing it with an external database for commercial blockchain deployments.

Conclusion

Being able to scale to 100 TPS is a great achievement for Nxt, however we are not stopping here. For Ardor, we are planning to invest a lot of resources into load testing and scalability to make it an even more scalable blockchain solution.