Simple transactions are not so simple. ( not sure if this is technically issue )
matsuro-hadouken opened this issue · 6 comments
Following OT4-T1 Simple bulk transactions chapter:
- Send 100 simple transfers per hour.
It comes to my attention processing "simple" transaction took approximatly not less then 37 seconds. Which is about 97.2 transactions per hour. My thoughts was, to many spam make my baker slow for whatever reason ( ID: 11afdb30f8d0994e ).
To proof this theory I setup gate node on another server ( 10 core, 64 RAM VPS ) without baker enabled ( ID: eaff28c3b00ae023 ).
After checking "simple transaction" trough new non-baker gate, timing apparently is the same 37 second minimum processing time.
Is this correct timing for single deploy or something is wrong ?
Thank you !
Can you clarify what exactly you are measuring? What does "processing" mean?
If you look at the network dashboard you will see that most blocks have a number of transactions, including simple transfers, and average block times are around 10s, so it cannot be that each of them takes 37s or more.
When you send a simple transfer with concordium-client it will by default wait until the transaction is finalized. In some cases it will be more than 37s, simply due to the random nature of when blocks are produced.
@abizjak transactions pushed in a loop on my side:
"while true ..."
concordium-client transaction send-gtu --amount "$amount" --receiver "$receiver" --sender "$sender" --no-confirm --no-wait
"done."
This loop can't go faster then 37 seconds, and timing is always around 37.xx , here is no delay in the loop, mean approximatly 97.2 valid transaction per hour if no single deploy failed.
From my perspective - in today statistics I had 4 times about 38 minutes to make 100 send-gtu transactions with "--no-confirm" (and without "--no-wait"), and once - 50 minutes.
@matsuro-hadouken I cannot reproduce that unfortunately. A command like you posted executes essentially immediately on my test setup, the most time consuming part being the password input. What system is the node running on? It might also be helpful to have the account address you are trying to send from.
@sparkuss since you are not running with --no-wait (and it is correct to do so) this would mean that the average time for a transaction to be finalized (from the start of your command) is 22.8s, which is not so unusual. Remember that the time the command stops is when your node becomes aware that the block which contains the transaction is finalized.
No user response; issue closed.
@matsuro-hadouken I cannot reproduce that unfortunately. A command like you posted executes essentially immediately on my test setup, the most time consuming part being the password input. What system is the node running on? It might also be helpful to have the account address you are trying to send from.
@sparkuss since you are not running with
--no-wait(and it is correct to do so) this would mean that the average time for a transaction to be finalized (from the start of your command) is 22.8s, which is not so unusual. Remember that the time the command stops is when your node becomes aware that the block which contains the transaction is finalized.
On my side transaction generated fast, but it takes time before pasword prompt popup, this is where it get delayed. I believe if wallet was setup on test keychain without password then it will be close to instant. The issue is somewhere in the description process and not in actual tx generation and broadcast.