Our developer team is here again to bring you another DCore milestone! We’ve been working hard on the new version of DCore, Version 1.3.0, and our testing shows that it is able to process more than 2,000 transactions per second!
We are very excited about this, but before we get ahead of ourselves, let’s take a moment to have an inside look from our development team to explore what tests and parameters were used to accomplish these awesome results. Strap yourself in, things are about to get “techy”!
Firstly, we must define what it means to have “2,000+ transactions per second”. To be more specific, the transactions we are talking about must be constantly accepted (not only in peaks), have no lost transactions, and no disabled verifying signatures when receiving transactions from the network.
We must take into account several things like the topology of the testing network, tested operations and hardware. In this test, we used physical hardware. This requires more space since you must put together several physical machines, connect them through an ethernet switch, etc., so we chose a simple model:
One Linux Ubuntu server 16.04 running DCore mining node configured with 11 miners and two other computers with Windows running DCore node and transaction_gun utility. In a small network, we reach the same result with all 11 miners on one server and with miners allocated on more machines, for example, four machines, where every machine has two miners and a fifth machine that has three miners. The result will be the same due to the fact that miners have assigned time slots and they verify transactions into blocks only within this time slot.
Linux server hardware:
HP Compaq Elite 8300 CMT PC ALL with CPU i7–3770 3.4GHz 4 cores, system disk — SSD, RAM 8GB.
One computer with average HW parameters is able to send (max) around 1,800 transactions per second with the help of our transaction_gun utility. Therefore, we decided to use two computers for this test:
Computer hardware:
ThinkPad L560 with CPU i7 6600U, 2.6–2.8GHz, RAM 8GB, SSD disk, Windows 10
ThinkPad E570 with CPU i7 7500U, 2.7–2.9 GHz, RAM 8GB, SSD disk, Windows 10
All three machines were connected via Ethernet cables. Regarding our experience, if you have good connectivity in your wireless network, then you can use wireless instead, but when the server is near 2000 tx/sec, then the CPU cores can be loaded from 70% to 100% and the needed network bandwidth can be up to 10Mbits per machine.
Such an environment can be sensitive to network latency, so to avoid any problems, we chose to use a reliable connection, an ethernet cable. It is also important to stop processes which have high CPU consumption on all three machines, in other words, to use dedicated machines.
DCore nodes were run on a private testnet network dedicated for benchmarks. The DCore node on Linux is configured with the recommended configuration.
Two non-mining nodes are connected to a node running on a Linux server, which acts as a seed node.
Transaction_gun is a utility developed for benchmarks. It sends a flood of transactions to locally running DCore node, and DCore node broadcasts them to the DCore network. Every transaction contains a single transfer operation which transfers a small amount of DCT between accounts.
We created four testing accounts. When the DCore node is running on a computer and it is synchronized with the Linux server, the next step is to start transaction_gun. We used two instances on every computer and every instance sent DCT to different testing accounts.
We wanted to test the limit for constant processing of transactions, so we sent a sufficient amount of transactions over a longer time period, rather than making a big flood in a short time. We used 80,000 transactions from every instance sent on the highest possible speed, which took a little over 2 minutes.
Transaction_gun first creates all the transactions, signs them, and then it is prepared to send at the desired time. It is important to start all instances at once due to the comfortable reading of results. Ideally, the computers should be of the same power or type. If one of them sends transactions more quickly, then you must track the slower one and remember the number of sent transactions at the time when the first one finishes sending.
After the test is finished, we can use a simple calculation: Transactions per second = (number of sent transactions)/time.
In our testing environment, we measured from 2,100 to 2,500 tx/sec without any lost transactions. When we tried to add another two machines, we reached higher speeds but we lost some of the transactions. Transactions are lost when the Linux server has a very high CPU load and the DCore node is not able to process all the tx received from the network.
In order to verify that transactions were not lost and all received transactions were processed, we added an output to the console. This told us the number of all processed transactions and we could simply see that the number of sent transactions equaled the number of processed transactions, therefore nothing was lost.
We performed many tests with four types of CPU’s and reached the best results of 2,000+ transactions per second with an Intel CPU i7–3770 3.4GHz 4 cores.
We are very pleased with the results of our testing and hope to reach new milestones as we continue to advance our DCore technology and platform. As always, if you want to stay up-to-date with the latest news about DECENT, follow us on social media and join our Telegram.
Originally published at decent.ch on August 23, 2018.
