Added a counter to see how many transactions has been pushed.

[haseeb1431]

Added a counter to show the number of transaction we are sending. E.g. In some experiments, we stopped mining and continued sending transactions but submission slowed down after certain no of transactions (5K or so) probably because of the eth node meomory etc. Having a counter will let us see how many we already sent

[drandreaskrueger]

Good idea, thanks.

A hint: I usually don't look at the send.py output anymore, but just watch the output of tps.py. That shows the total count of transactions in all counted blocks, ie. how many transactions actually arrived.
Which is admittedly not exactly the same but if it is a private chain only used by me, then it is close to the info that we want to see, no?

But I do not mind a counter also in the send.py - The next public release is only a very short time away, that is why I won't merge this now, but afterwards.

I am curious:

E.g. In some experiments, we stopped mining and continued sending transactions but

Please tell me a bit about your context, in which you are using chainhammer. Excited to hear more.

probably because of the eth node meomory etc

Yes, most of the clients are out of the box not configured to accept that many transactions in such a short time. For each we need to find the best CLI arguments to configure them.

When you find out config knowledge that goes past what I documented (e.g. in results/ and reproduce.md) please tell me. I also want to provide a set of good settings for high load configurations of the main clients.

Which Ethereum client/s are your testing? What are your best settings?

Thanks a lot for the pull request! Delighted that I see people using my work, getting feedback, and now even code improvements, cool. Stay tuned for the next release version, I have made huge progress, especially in terms of automation, and better diagrams.

[haseeb1431]

Yes, it does but not when miner is stopped actually.

So we were running our nodes in same region and then different regions as well. For example a node in AWS US and other in EU-central makes a private network. if we have block-chain in US region submitting transaction to eu node, the transaction submission speed will be impacted by network latency. So we might be submitting less transactions than the actual network could process actually which will lead to incorrect results. So to counter that issue, we were doing following steps

1. Running tps in one terminal and deploy in the second terminal
2. stop the mining and then do send in the second terminal
3. once all the transactions are submitted/queue, start the mining and see how quickly nodes can process the transactions

we needed it because we were using smaller block intervals e.g. 1 second and transaction processing was faster than the submission rate.

[drandreaskrueger]

Interesting, very interesting. Thanks for the explanations,

Can I send you an email, @haseeb1431 ?

[haseeb1431]

sure, that works for me.

[drandreaskrueger]

How? Perhaps send me a twitter DM, or put your email address into your github profile for a one day?

[haseeb1431]

My handle is haseeb1431. you can send me email at gmail with the same as well.

[truthadjustr]

I think, that Chainhammer should not use a validator node account. Instead, the transaction signing should be done in python web3 side. By making it more realistic, it will be more usable in other blockchains. The counter that is mentioned here, is actually, the nonce that I am referring to in the issue I logged here