drandreaskrueger / chainhammer

fire many transactions at Ethereum node, then produce diagrams of TPS, blocktime, gasUsed and gasLimit, and blocksize.
Other
122 stars 56 forks source link

Remote Ethereum Node On AWS #20

Open atonughosh opened 4 years ago

atonughosh commented 4 years ago

How do I connect to the remote Ethereum node on AWS? I want to test it.

drandreaskrueger commented 4 years ago

to the remote Ethereum node on AWS?

not sure I understand.

Do these cloud node benchmarking instructions help you perhaps? https://github.com/drandreaskrueger/chainhammer/blob/master/docs/azure.md

atonughosh commented 4 years ago

Hi, I hope you're good in this pandemic situation.

Yes, I have deployed the Ethereum nodes on AWS EC2. I could connect to the RPC by modifying the config.py file. I also launched the test. Used this command from your video on YouTube. Command Used by Me: CH_TXS=5000 CH_THREADING="threaded2 20" ./run.sh experiment01 geth-clique

Attached is the result.

My gas usage is reaching the limit. Please let me know what is wrong. I am on my private Ethereum network. Ethereum v1.9. Using AWS t3.2xl, Ubuntu 18.04 for ethereum nodes. 2 nodes. Both mining. Capture

drandreaskrueger commented 4 years ago

Great. At first sight, that looks good. Happy for you, that you made it this far. And all on your own. Well done.

Perhaps you can help me to make the instructions better? Your initial question sounded as if you had been stuck somewhere near the beginning?

Anyways ...:

My gas usage is reaching the limit.

Yes, that's what the fourth diagram was intended for, to be able to detect such situations. Nice.

Let's look into the details. Please click on every link, and have a longer look at each of the files.

Your beginning is: ./run.sh experiment01 geth-clique which is passing on your choice geth-clique here: https://github.com/drandreaskrueger/chainhammer/blob/c17a3425aa475005b5e5d52ca886f54b49f2e1da/run.sh#L61

so networks/geth-clique-start.sh is called to start the network. Specifically the docker-compose in this cloned repo: https://github.com/drandreaskrueger/chainhammer/blob/cb1a3cdfe24ab7fa63ceb35c75d4d01bf42a5ee8/networks/geth-clique-start.sh#L7

So let's look into that repo, which was cloned during the initial setup phase https://github.com/drandreaskrueger/chainhammer/blob/47d4f3a6ead49225833455a6d7712e78366a9a32/scripts/install-network-starters.sh#L23-L29

Now, when we look into that repo https://github.com/drandreaskrueger/geth-dev.git ...

... we find the genesis.json file with the line "gasLimit": "0x2625A00"

It's been quite a while so I might misremember how Ethereum works, but I think that decimal 40000000 is the value to change. If not, please get back to me.

And:

Keep me in the loop please. May I ask what is the purpose of your trying out chainhammer?
Thanks.

drandreaskrueger commented 4 years ago

Ah, I see. 1 seconds block time. So you have already changed the genesis ? Then look around where you did that choice of 1 second, the gasLimit cannot be far from there too.

However - I have my doubts whether 1 second per block is a good idea.

What are the specs that the geth creators are giving for their current version (of geth clique), in terms of blocktime? Perhaps find their chat, and ask them?

atonughosh commented 4 years ago

Great. At first sight, that looks good. Happy for you, that you made it this far. And all on your own. Well done.

Perhaps you can help me to make the instructions better? Your initial question sounded as if you had been stuck somewhere near the beginning?

Anyways ...:

My gas usage is reaching the limit.

Yes, that's what the fourth diagram was intended for, to be able to detect such situations. Nice.

Let's look into the details. Please click on every link, and have a longer look at each of the files.

Your beginning is: ./run.sh experiment01 geth-clique which is passing on your choice geth-clique here:

https://github.com/drandreaskrueger/chainhammer/blob/c17a3425aa475005b5e5d52ca886f54b49f2e1da/run.sh#L61

so networks/geth-clique-start.sh is called to start the network. Specifically the docker-compose in this cloned repo:

https://github.com/drandreaskrueger/chainhammer/blob/cb1a3cdfe24ab7fa63ceb35c75d4d01bf42a5ee8/networks/geth-clique-start.sh#L7

So let's look into that repo, which was cloned during the initial setup phase

https://github.com/drandreaskrueger/chainhammer/blob/47d4f3a6ead49225833455a6d7712e78366a9a32/scripts/install-network-starters.sh#L23-L29

Now, when we look into that repo https://github.com/drandreaskrueger/geth-dev.git ...

... we find the genesis.json file with the line "gasLimit": "0x2625A00"

It's been quite a while so I might misremember how Ethereum works, but I think that decimal 40000000 is the value to change. If not, please get back to me.

And:

Keep me in the loop please. May I ask what is the purpose of your trying out chainhammer? Thanks.

Hi, Thanks for the awesome proposal of helping you with the instructions. Yes, initially I was stuck with in beginning. I'll just have a look into the resources that you shared and try to figure out what's going wrong. I shall experiment more with it and shall keep you posted.

Attached is my genesis file that I have used to initialize my private network.

I am an MTech student in Computer Science & Engineering from India. I'm working on my project. I have proposed a system for Cloud Forensics that is Blockchain Based. I need to benchmark my proposed system. I found your tool through Google. I liked it. Also I liked your video on YouTube. That's why I'm using it.

Thanks again for asking me about the instructions. I'm more than happy to help you.

gen

drandreaskrueger commented 4 years ago

I see. Thanks.

Thanks for the explanations why you are using chainhammer. Good to know. It can very probably help you to optimise your throughput. If you want to, please write a chapter or a page about your project, I would like to link to it in other-projects.md#projects-using-chainhammer. No hurry, just get back to me eventually. Thanks a lot.

... Cloud Forensics that is Blockchain Based. I need to benchmark my proposed system.

Ah, cool.
I guess you have your own smart contract for that?

What about this idea:
Identify the probable bottleneck in your system (usually that's stuff related to (either bots running often and in many places concurrently, or) end consumers as they are the largest group in most cases. But even their several smart contract calls are of a very different nature, usually. So: Choose the most frequent one. Let's call that candidate MyContract.bottleneck(args) for now.).

For that, you swap out my "store a simple number" call out of the python send.py code, and instead swap in a call to your MyContract.bottleneck(args) into the mass sending routine.
Have a look here: https://github.com/drandreaskrueger/chainhammer/blob/e999a7d3c9209447fca6b80a8665458d94fb8edd/hammer/send.py#L189-L194 and here: https://github.com/drandreaskrueger/chainhammer/blob/f8e5d04a4ade5f0f8644d83ef02e254b138664d2/hammer/contract.sol#L9-L17

Benchmarking your own call will give you a much more realistic assessment, as it's adapted to your system. But that is step 2. Let's first look into optimising your blockchain setup while still being SmartContract agnostic.

"gasLimit" : "2100000"

ah, so decimal values are allowed too. Good to know.

By now, you have tried increasing that value, right?
You must purge the whole chain probably, and restart with a new chain.

Please tell me when you got rid of your hitting the block limits.

Another thing: You do not have a

"config" : ... "clique": { "period": 5, "epoch": ... }

so you are running it with proof of work - with miners? What is your rationale for that? How can you guarantee enough mining power to not be overwhelmed by malicious miners, taking over your system? Or do you target the Ethereum public chain eventually?

Will your system NEED the proof of work properties (e.g. censorship resistance), or are you using blockchain due to other reasons (e.g. immutability, security, consensus, notarisation, etc). In other words ... have you looked into proof of authority yet?

Also I liked your video on YouTube. That's why I'm using it.

Nice one. I am not particularly proud of that boring and primitive video - but I think it does the trick, of giving a short enough introduction into some of the moving parts of this system.

Yes, initially I was stuck with in beginning.

How could I have made that easier for you?

atonughosh commented 4 years ago

Hello,

I was waiting for your reply :) I'm learning a lot from you. Thanks in advance.

If you want to, please write a chapter or a page about your project...

I would love to do that. Once I'm satisfied with my project's functionality and performance. I am surely going to write it.

I guess you have your own smart contract for that?

Yes, I have my own smart contract.

What about this idea: Please tell me when you got rid of your hitting the block limits.

I was caught up with the project report writing, resuming the work today. Shall let you know all signs of progress.

"config" : ... "clique": { "period": 5, "epoch": ... }

I don't understand this part. Could you please explain that?

are you using blockchain due to other reasons (e.g. immutability, security, consensus, notarisation, etc)

I'm using "Immutability". That is what I need the most. But I'm open to better algorithms as long as I'm getting the Immutability out of my system. But immutability is IMPORTANT.

How could I have made that easier for you?

Your presentation was nice. Calm and composed. Moreover, I followed the directories that you were moving in and the commands that you issued. I related those to my experiment.

I just figured out, I couldn't understand one more thing in the graph generated by Chainhammer. Attached is the TPS graph. I rewatched the video on YouTube too. There you said "the transactions have been smoothed over...." I do not understand the legend of the graph. Why are there 4 types of them? "TPS_1blk", "TPS_3blks", "TPS_5blks" and "TPS_10blks". What are these? TPS

drandreaskrueger commented 4 years ago

I mentioned this, because your genesis.json did not contain the config.clique definitions:

"config" : ... "clique": { "period": 5, "epoch": ... }

I don't understand this part. Could you please explain that?

compare my genesis.json https://github.com/drandreaskrueger/geth-dev/blob/master/miner/genesis.json with yours. Yours is lacking that.

I am a bit disconnected now from Ethereum stuff, it's been a long time ago that I did all this. I am actually not sure WHERE the geth is switched from ProofOfWork algo to the ProofOfAuthority algo "clique".

Here are the commandline switches: (*)
https://github.com/drandreaskrueger/geth-dev/blob/master/miner/Dockerfile#L27
https://github.com/drandreaskrueger/geth-dev/blob/master/node/Dockerfile#L27
https://github.com/ethereum/go-ethereum/wiki/Command-Line-Options

But as the commandline switches used there (*) do not contain anything that could cause that switching of geth from PoW to PoA ... I suspect that it's the genesis.json which makes geth run PoA instead of PoW. But please do your own research, and find it out for sure. Then update me please. Thanks. Actually ... probably it's all here: https://geth.ethereum.org/docs/interface/private-network . If not, find their chat (gitter? riot? slack?) and just ask them.


you said "the transactions have been smoothed over...." I do not understand the legend of the graph.

TPS_1blk is the actual TPS for that single block
TPS_10blks is an averaged TPS, with a window size of 10 blocks.

Why are there 4 types of them?

because I didn't know which ones would turn out as the best ones.

Later I realized it's very much dependent on the situation, so I left them all in.

If your chain is in totally "Zen like" stable tranquillity ... then all of them are ~identical after ~10 blocks. Almost never happens though. Short term fluctuations you'll better see in the blue and yellow.

Does that make sense?


I'm using "Immutability".

Good. I suggest you read up on PoW versus PoA - and then probably you want to go for PoA.

atonughosh commented 4 years ago

compare my genesis.json https://github.com/drandreaskrueger/geth- OK, doing that right away.

I suspect that it's the genesis.json which makes geth run PoA instead of PoW. But please do your > own research, and find it out for sure. Then update me please

Modifying it too once I find it out. Shall let you know once done with it.

Does that make sense?

Absolutely

Thanks a lot.

atonughosh commented 4 years ago

Hello,

Fixed the Gas usage issue.

I think the block time is not super stable. Why is that?

Please provide your valuable feedback on the results for the attached results for 5k and 10k transactions performed with PoW with Ethereum deployed on AWS EC2 t3.2xlarge instance.

5k

10k

Thanks & Regards, Atonu Ghosh

drandreaskrueger commented 4 years ago

Fixed the Gas usage issue.

Very good. You found the correct spot to tweak it. Where was it?


Please provide your valuable feedback ... performed with PoW

I have zero experience with trying chainhammer on PoW. It was still a TODO (see docs/TODO.md).
So what you are trying is actually quite interesting. Please you explore that more. Perhaps you can document it in a long markdown file, similar to these: results/......md <== while trying to understand what exactly is going on, I documented each run. Just chronologically, one above the other. You see what I mean? You could do something similar while exploring ProofOfWork.


5k and 10k transactions

Better do more. Or ... many more.
You don't only want to have a handful of blocks.


the block time is not super stable. Why is that?

You must read up on the concept of "difficulty".
In PoW, there is actually no "block time" as input parameter. Instead it is a consequence of difficulty and hashpower, and the stochastic process of mining.

drandreaskrueger commented 4 years ago

P.S.:

plus ... not 100% sure if that is the case here (to find out, just download any block, and explore its datastructure) but the timestamp in the blockheader of some of the ethereum/parity/quroum/geth/etc.... versions ... is actually not float but integer.

That could be the reason why you see so many blocktime 1.

Increase the difficulty much, and that will change.

atonughosh commented 4 years ago

Hello,

Very good. You found the correct spot to tweak it. Where was it?

I got it done by setting a larger gas limit in the genesis block.

You see what I mean?

Yes, I do understand. I'm preparing it. Just to confirm, "CH_TXS=5000 CH_THREADING="threaded2 20" ./run.sh experiment01 geth-clique" issuing this command is in turn giving me results of my PoW implemented?

Better do more. Or ... many more.

Performing more experiments now.

Instead it is a consequence of difficulty and hashpower, and the stochastic process of mining.

Got it and shall find out more on it.

Thanks & Regards, Atonu Ghosh

drandreaskrueger commented 4 years ago

Just to confirm, "CH_TXS=5000 CH_THREADING="threaded2 20" ./run.sh experiment01 geth-clique" issuing this command is in turn giving me results of my PoW implemented?

To find out, let's do one thing: You (*) reboot (so that you machine is in a defined state) and delete the content of your chainhammer/logs folder. Then you run

CH_TXS=20000 CH_THREADING="threaded2 20" ./run.sh experiment01 geth-clique

and (perhaps additionally copy-paste everything from stdout into another file, and) zip all log files, and attach them to a next comment here.

Then I can have a look.

drandreaskrueger commented 4 years ago

plus

history | tail -n 50

and crop it to anything that you did since the reboot (*).

atonughosh commented 4 years ago

Hello,

Please find the folder attached. It contains the Results, Logs & Terminal Output.

The network was a two peered network. both peers mining. Experiments performed for 5k, 10k, 15k and 20k transactions.

Please check and let me know if PoW is being reported by Chainhammer. I haven't implemented anything other than PoW.

Thanks & Regards, Atonu Ghosh

Results_&_Logs.zip

drandreaskrueger commented 4 years ago

Hi!
thanks, that looks VERY good. Studying your files now.
Many thanks for being so precise! Andreas

drandreaskrueger commented 4 years ago

What about the chainhammer logs/ folder?

Have a look at your Experiments_Terminal_Output.txt, it mentions them: logs/tps.py.log logs/deploy.py.log logs/send.py.log logs/network.log etc

that's what I meant when I said

and delete the content of your chainhammer/logs folder

that you afterwards zip it and send it to me.

I suggest study each of those *.log files, they will tell you more what is going on behind the scenes.

At first sight, I can already see this in the Experiments_Terminal_Output.txt:

=============================
= stop
=============================
Stopping PID 27855 first with -SIGINT then with -9
sleep 5
kill: (27855): No such process

so very probably the logs/network.log will tell you that the script geth-clique-start.sh could not start a geth process - because the port was already taken. Right?

Instead of

CH_TXS=20000 CH_THREADING="threaded2 20" ./run.sh experiment01 geth-clique

start your with

CH_TXS=20000 CH_THREADING="threaded2 20" ./run.sh experiment01

If you want to run it on your own instance of Ethereum.

see: https://github.com/drandreaskrueger/chainhammer/blob/c17a3425aa475005b5e5d52ca886f54b49f2e1da/run.sh#L19-L20

and https://github.com/drandreaskrueger/chainhammer/blob/c17a3425aa475005b5e5d52ca886f54b49f2e1da/run.sh#L59-L63

but let me see what else I can discover in your zip ... [ctd]

drandreaskrueger commented 4 years ago

Node_2_Log/eth.log:

...
INFO [06-13|01:54:06.361] Generating DAG in progress               epoch=0 percentage=70 elapsed=23.527s
INFO [06-13|01:54:06.693] Generating DAG in progress               epoch=0 percentage=71 elapsed=23.858s
INFO [06-13|01:54:07.025] Generating DAG in progress               epoch=0 percentage=72 elapsed=24.190s
INFO [06-13|01:54:07.356] Generating DAG in progress               epoch=0 percentage=73 elapsed=24.522s
INFO [06-13|01:54:07.689] Generating DAG in progress               epoch=0 percentage=74 elapsed=24.854s
INFO [06-13|01:54:08.021] Generating DAG in progress               epoch=0 percentage=75 elapsed=25.186s
INFO [06-13|01:54:08.352] Generating DAG in progress               epoch=0 percentage=76 elapsed=25.517s
INFO [06-13|01:54:08.691] Generating DAG in progress               epoch=0 percentage=77 elapsed=25.857s
...

ethash creates that huge https://eth.wiki/concepts/ethash/dag

you must wait until that has finished, before you start any experiment.

but it needs to be created only once.

drandreaskrueger commented 4 years ago

20k.png 5k.pn ...

Not sure about that blocktime. Perhaps your initial difficulty is much too low? As I said, I had never unleashed chainhammer onto a proof of work variant of ethereum, that was still in the TODO.md ("Vanilla Ethereum PoW ... to get the baseline TPS using my scripts"). Please you do so, and document it well please, like mentioned above. I could later include that work of yours into this repo here.

For now, I suggest you find genesis.json settings with which you get a block time of a few seconds (like 5 or 10 seconds) right from the start.

Or ... completely drop mining and proof of work - and look into geth clique instead, see https://github.com/drandreaskrueger/chainhammer/issues/20#issuecomment-642367984

drandreaskrueger commented 4 years ago

in your 13th_June_Two_Peer_Results/results/runs/Geth_20200613-0159_txs20000.html

look at this:

block 324 | new #TX   0
block 325 | new #TX   0
block 327 | new #TX 933
block 329 | new #TX 1045
block 330 | new #TX   0
block 331 | new #TX 1042
block 333 | new #TX 208
block 334 | new #TX   0
block 336 | new #TX 1107
block 337 | new #TX 896
block 338 | new #TX 119
block 340 | new #TX 1079
block 341 | new #TX   0
block 342 | new #TX 1110
etc.

It doesn't show every block because between each polling it sleeps 300 milliseconds, see here: https://github.com/drandreaskrueger/chainhammer/blob/d954cdd8bbadae380242b89df66d23259681d17a/hammer/tps.py#L236

But we can already see that your combination of settings (gasLimit, difficulty, hashrate of your miners, etc) creates a very "stuttery" chain.

Sometimes even with empty blocks in between.

I suggest you understand better how those parameters actually interact, and then try out other combinations.

You'd want a smoother chain, right?

I don't think it makes sense at all to aim for block times below 2 seconds. Or even 5 seconds.

drandreaskrueger commented 4 years ago

I think that's it for now. Can you continue from here? Any other questions?

This #20 here is a VERY good issue. May it be an example for future experimenting with chainhammer.

Such a log ZIP can serve as reference for future communication (logs/* added by me, for illustration):

Screenshot from 2020-06-15 11-29-08

It helps a lot, to have all that. Thanks. Again: Well done

atonughosh commented 4 years ago

Hello,

start your with CH_TXS=20000 CH_THREADING="threaded2 20" > ./run.sh experiment01

I did this with the experiments now. It's giving no more such issues.

Or ... completely drop mining and proof of work

I'm implementing both PoW and PoA to contrast their performance in my project.

I don't think it makes sense at all to aim for block > times below 2 seconds. Or even 5 seconds.

Now performing all experiments with block times higher than 8 Seconds. The chains have become smoother.

I think that's it for now. Can you continue from here? Any other questions?

I think I can perform the experiments with confidence now. Thanks a lot for the great help that you have been doing. I really appreciate that. Your guidance has been instrumental in my experiments.

Lastly, I would like to know, I have been noticing that for a number of experiments, the gas limit plot instead of of straight line becomes bumpy! Why is that happening? Is it because gas limit is limiting the gas used i.e. the gas needed for the transactions?

Shall create the docs you asked me for. Please allow me some time.

Thanks & Regards Atonu Ghosh

drandreaskrueger commented 4 years ago

the gas limit plot instead of of straight line becomes bumpy!

The blue line? Please share one of those pics. Perhaps it's because of https://www.google.com/search?q=ethereum+block+gas+limit+adaptive ?

Now performing all experiments with block times higher than 8 Seconds. The chains have become smoother.

Great. Make sure to eventually document all your setting choices too. They can be very helpful for anyone who wants to learn from your experiments.

I'm implementing both PoW and PoA to contrast their performance in my project.

That is great. Always wanted to see the difference, just didn't have the time.

Shall create the docs you asked me for.

Perfect. Thanks. Much appreciated.

Please allow me some time.

No rush. And ... enjoy it :-)

I think I can perform the experiments with confidence now.

Great, I am happy. Just get back to me with any questions.

drandreaskrueger commented 4 years ago

Should I close this issue?

atonughosh commented 4 years ago

Should I close this issue?

Yes, but how do I contact you regarding the contributions I would make?

drandreaskrueger commented 4 years ago

Let's keep it open then.

atonughosh commented 4 years ago

Let's keep it open then.

Yes, please let it be open. Shall complete my final semester exam shortly and then I'll be able to contribute to your documentation.

drandreaskrueger commented 4 years ago

Good luck with your exam then.

Great. Didn't want to put you under stress, just cleaning up a bit. Take your time.