eth_estimateGas performance

[ryanschneider]

System information

Geth version: 1.8.0-unstable-56152b31 (also 1.7.3-stable-4bb3c89d)
OS & Version: Windows/Linux/OSX
Commit hash : 56152b31ac251d1cc68fcddbdad159ba5234c415

Expected behaviour

eth_estimateGas is more or less as performant as eth_call.

Actual behaviour

eth_estimateGas takes seconds or minutes to run.

Steps to reproduce the behaviour

I don't have a sure fire repro but have seen it happen if you make the call just a couple seconds after starting geth, or sometimes it takes hours before it gets into this state.

However, during testing I noticed two things:

• EstimateGas does a binary search instead of using the gasUsed returned from doCall. Why?
• It also uses rpc.PendingBlockNumber, with no option for a block param (see internal/ethapi: eth_estimateGas should take block number #2586)

So, as a test I switched to rpc.LatestBlockNumber in ryanschneider@7df8498, and was unable to reproduce the issue after throwing a lot of test traffic at it.

I'd love to help track down the issue, but don't have clarity into why the binary search is used. Also my current theory is that there is contention on the pending block, does that sounds like a reasonable place to look?

Backtrace

I'll get a debug.stacks output from either 1.7.3 or master here the next time I see the issue.

[karalabe]

The binary search is needed due to funky gas dynamics and allowances in various EVM opcodes. For example, doing a CALL forwards 63/64 of the available gas to the called contract. Which means, even though the internal call might use N amount of gas, the opcode to be called actually requires (N/63*64). There's a similar issue with CALL stipends where a tiny amount of gas (1900) required by the opcode gets granted for free to the CALL, but won't get refunded if not used. This also makes the actual used amount and the required amount different.

Your other measurement that the pending state is slow vs. the latest block is fast is an intriguing find! I'll need to take a closer look at that.

[ryanschneider]

Thanks @karalabe , for what it's worth I changed some of our nodes to run w/ this commit (ryanschneider@8c95ba4) that just patches 1.7.3 to use latest and our 95% percentile response time from eth_estimateGas went from 5 seconds to 300ms.

[ryanschneider]

We need to collect more info, but we're seeing a similar level of slowness in eth_getTransactionByHash for txs that aren't mined yet, which hits the commented out part of the codepath here:

https://github.com/ryanschneider/go-ethereum/blob/dc78cb610d530765844df0833775358d737c47de/internal/ethapi/api.go#L979

So that seems to further my thinking that we're seeing some major contention on the pending transactions. Anything specific I can do to help debug?

[dovy]

So maybe I'm crazy, but why not just have a running process that updates the gas price with each transaction and then when someone asks for the gas price, the stored value is just returned? I know you're all trying to do this via the blockchain, but it seems like it's not ready for that. Wouldn't this be an appropriate and effective method to mitigate this deficiency?

[ryanschneider]

Your other measurement that the pending state is slow vs. the latest block is fast is an intriguing find! I'll need to take a closer look at that.

@karalabe I think I've fixed this in #16497, if you could take a look it'd be greatly appreciated!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.