60 TPS ? (parity aura v1.11.11)

[drandreaskrueger]

I am benchmarking Ethereum based PoA chains, with my toolbox chainhammer.

My initial results for a dockerized network of parity aura v1.11.8 nodes ...

... leaves space for improvements :-)

Initial -unoptimized- run:

More details here: https://gitlab.com/electronDLT/chainhammer/blob/master/parity.md#benchmarking

Please help ...

... by suggesting what we could try, to get this faster than 60 TPS.

(Ideally approx 8 times faster, to beat quorum IBFT.)

Thanks a lot!
Andreas

---

I'm running:

• Which Parity version?: v1.11.8
• Which operating system?: Linux
• How installed?: via docker
• Are you fully synchronized?: not relevant
• Which network are you connected to?: private chain
• Did you try to restart the node?: yes
• actual behavior slow
• expected behavior faster
• steps to reproduce: See parity.md.

[drandreaskrueger]

Hey @5chdn @Tbaut @ddorgan @AyushyaChitransh @gituser

Greetings from Berlin, web3summit.

Actually, who of you are you in Berlin now? We should meet up this week!

[ddorgan]

So I just did a test on a c5.xlarge but only using the --geth extra option and I'm seeing this:

blocknumber_start_here = 17
starting timer, at block 17 which has  1  transactions; at timecode 43450.223308099
block 17 | new #TX 661 / 4000 ms = 165.2 TPS_current | total: #TX  662 /  4.0 s = 166.9 TPS_average
block 18 | new #TX 775 / 4000 ms = 193.8 TPS_current | total: #TX 1437 /  8.0 s = 179.9 TPS_average
block 19 | new #TX 750 / 4000 ms = 187.5 TPS_current | total: #TX 2187 / 12.0 s = 182.4 TPS_average
block 20 | new #TX 763 / 4000 ms = 190.8 TPS_current | total: #TX 2950 / 16.0 s = 184.3 TPS_average
block 21 | new #TX 740 / 4000 ms = 185.0 TPS_current | total: #TX 3690 / 20.0 s = 184.4 TPS_average
block 22 | new #TX 740 / 4000 ms = 185.0 TPS_current | total: #TX 4430 / 24.0 s = 184.4 TPS_average
block 23 | new #TX 758 / 4000 ms = 189.5 TPS_curr, wient | total: #TX 5188 / 28.3 s = 183.2 TPS_average
block 24 | new #TX 717 / 4000 ms = 179.2 TPS_current | total: #TX 5905 / 32.0 s = 184.5 TPS_average
block 25 | new #TX 751 / 4000 ms = 187.8 TPS_current | total: #TX 6656 / 36.0 s = 184.8 TPS_average
block 26 | new #TX 712 / 4000 ms = 178.0 TPS_current | total: #TX 7368 / 40.0 s = 184.2 TPS_average
block 27 | new #TX 733 / 4000 ms = 183.2 TPS_current | total: #TX 8101 / 44.0 s = 184.1 TPS_average
block 28 | new #TX 728 / 4000 ms = 182.0 TPS_current | total: #TX 8829 / 48.0 s = 183.9 TPS_average
block 29 | new #TX 742 / 4000 ms = 185.5 TPS_current | total: #TX 9571 / 52.0 s = 183.9 TPS_average

Still seems quite single thread heavy though, will try with some options to speed that up.

[drandreaskrueger]

Great results. Looks very promising.

We have to find out how to prevent this https://github.com/paritytech/parity-ethereum/issues/9582 to always get to those results, consistently. Please let it run to the 20k end - perhaps even with more than 20k transactions, see config.py

And: Keep me in the loop whatever you find out together with Tomek.

Thanks again for your time on Thursday in the parity office. Great working with you!

Greetings from the train to Prague.

[drandreaskrueger]

just found this elsewhere:

... validation logic, can be separated into three sections:
• Validation that actions are internally consistent
• Validation that preconditions are met
• Modification of the application state
The read only aspects of this process can be conducted
in parallel, while modification which requires write access
must be conducted sequentially ...

is that also how parity is internally digesting multi-threaded transaction requests?

[ddorgan]

@drandreaskrueger let me come back to you on this.

The bottleneck is most probably the signing itself. I think for geth you are basically pre-signing them because the web3 library is too slow, right?

I may make a change to your script to do the same for parity so that transactions are signed before being submitted.

This would like up with the geth process, right?

[drandreaskrueger]

because the web3 library is too slow

Yes, for low (two digit) TPS it does not make a big difference, only 20% faster. But when I get into the hundreds of TPS, I see considerable gains (twice as fast) when bypassing web3 completely. Please have a quick look at these old experiments: https://github.com/drandreaskrueger/chainhammer/blob/master/log.md#sending-via-web3-versus-sending-via-rpc

---

basically pre-signing

Not sure we are talking about the same thing actually. Even when bypassing the web3.py library, I am using the RPC method = 'eth_sendTransaction.

Have a look at these two codepieces:

via web3

in https://github.com/drandreaskrueger/chainhammer/blob/93c40384a4d178bdb00cea491d15b14046471b72/send.py#L73-L93
it is simply this one liner https://github.com/drandreaskrueger/chainhammer/blob/93c40384a4d178bdb00cea491d15b14046471b72/send.py#L90

while

via RPC

in https://github.com/drandreaskrueger/chainhammer/blob/93c40384a4d178bdb00cea491d15b14046471b72/send.py#L106-L183 I am doing (contract_method_ID + argument_encoding --> payload), then (plus headers into arequests.post to call eth_sendTransaction), see here:
https://github.com/drandreaskrueger/chainhammer/blob/93c40384a4d178bdb00cea491d15b14046471b72/send.py#L178

choice

I switch between those two routes here https://github.com/drandreaskrueger/chainhammer/blob/93c40384a4d178bdb00cea491d15b14046471b72/send.py#L201

choice constant ROUTE is defined in config.py

---

to do the same for parity so that transactions are signed before being submitted. This would like up with the geth process, right?

No, no difference between the two.

As long as PARITY_UNLOCK_EACH_TRANSACTION=False https://github.com/drandreaskrueger/chainhammer/blob/93c40384a4d178bdb00cea491d15b14046471b72/config.py#L43 is False, chainhammer is talking to geth identically to how it is talking to parity.

---

EDIT: Nicer formatting now here in FAQ.md, plus I raised an issue with the web3.py guys ...

[drandreaskrueger]

see above. Plus then:

The bottleneck is most probably the signing itself.

I suggest you compare the tx signing part of the geth go code with the parity rust code.

[drandreaskrueger]

chainhammer v55

The newest version is fully automated - you run & analyze a whole experiment with one or two CLI lines. I am optimistic that you will now find a clever combination of parity CLI switches to speed it up. Good luck.

Because of general interest, I have created this new issue: https://github.com/paritytech/parity-ethereum/issues/10382

[5chdn]

Thanks for sharing :+1:

[drandreaskrueger]

closed this

So you want to track possible speed improvements in the new issue. Yes, that makes sense.