# how estimate average time for transactions to smart contract

I have created a decentralized application on the Ethereum Blockchain network. This application receives data from different addresses on the blockchain network and saves this data in the blockchain network. This data is sent as parameters, how do I calculate the response time for these transactions in milliseconds. For example: Response time in milliseconds for reading data from the proposed smart contracts when the number of transactions = 1 and when the number of transactions is 100,200,300 and so on.

From what I understand, you are trying to estimate the time spent by calling a smart-contract (specifically a read call). In other words, how long does it take for a transaction to be processed by the blockchain?

Both read and write calls are sent as transactions, however, the latter requires mining and costs gas since it changes the state of the blockchain and requires consensus, while the former does not. The read call is just a database lookup that fetches the requested values from the blockchain, which is performed locally by the blockchain node that you are connected to.

(I am assuming that you already have established a connection to a blockchain node and that you are able to issue the calls)

For a read call, which does not require mining: You will have to record the time prior to calling the smart-contract (i.e. issuing the RPC call), let us call it t0, and record the time after the node responds to that call (i.e. when the requested value is returned), let us call it t1.

The time spent is simply, t1 - t0.

For a write call, which requires mining: t0 should be captured prior to sending the transaction and t1 should be captured when the confirmation message of that transaction is returned.

As above, the time spent is t1 - t0.

How to program it depends on what programming language you are using. For example, in Golang, you may use t0 = time.Now() to record the time at a specific point, and then use time.Now().Sub(t0) to get the duration (t1 - t0).

• The average time would be the summation of the recorded durations divided by the number of transactions
– isra
Commented Oct 5, 2020 at 14:03

First, we need to distinguish between transactions and RPCs (remote procedure calls), since you seem to be regarding them as if they were the same.

A transaction changes the state of the blockchain, i.e., the balances of some accounts and/or the values of some state variables in some contracts.

As such, it is executed by miners, who tend to choose transactions of `low gas-limit / high gas-price` first.

Therefore, the execution time of a transaction depends mostly on these two parameters.

In fact, since setting a high gas-limit doesn't cost anything (you get charged only for the actual gas being used), the primary motivation for not setting it to the maximum possible is so that miners would pick your transaction more quickly.

So in short, set the gas-limit of every transaction to the minimum required, and then set the gas-price to however much you're willing to pay in order to get it executed fast enough.

An RPC, on the other hand, only reads data from the blockchain.

Hence no mining is required, and execution time depends largely on your node capabilities, such as network connection, cache configuration, storage type, bandwidth limitation and so forth.

• Note that despite the gas-price being the primary factor controlling the execution time of a transaction, there is no way to predict how fast a transaction will be executed for a given gas price, since the network basically behaves like an "auction" - in times of high demand, you need to offer a higher gas-price in order to strive for the same execution time that you'd get in times of low demand. The general approach on this problem is to choose a gas-price relatively to the average or median gas-price of the last N transaction. Commented Oct 3, 2020 at 0:08
• Yes, I get what you mean. My question is how do I calculate Response time in milliseconds for reading data from the proposed smart contracts Commented Oct 3, 2020 at 5:28
• @esraa: Did you even read the answer??? It is explained in the last sentence! Commented Oct 3, 2020 at 8:28