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.