Conversation
2. conditional yield in processQueue
…ock is processed, forked_chain loops over all transactions and calls computeRlpHash(tx) for every one — i.e. re-RLP-encodes and hashes each tx. These hashes were already computed during RLP decode in ethBlock(payload, .... For a 150-tx block that's ~150 × ~20µs ≈ 3ms of wasted work per payload, on the critical path. 2. non-blocking engine_api enqueue. When the FC action queue is at MaxQueueSize=128, queueImportBlock and queueForkChoice call await c.queue.addLast(item) which suspends the caller until space frees up. Under burst load the CL sees unbounded tail latency rather than a clean SYNCING response, and the CL will eventually time out.
|
Unsure about the 4th change, not sure if it's the best idea. Or we should just let the engineAPI timeout instead for this case. |
| blockAccessList: Opt[BlockAccessListRef], | ||
| finalized: bool | ||
| finalized: bool, | ||
| txHashes: Opt[seq[Hash32]] = Opt.none(seq[Hash32]) |
There was a problem hiding this comment.
Don't need to list the type here explicitly since it can infer it from the default value.
| await c.queue.addLast(item) | ||
| if c.queue.full: | ||
| debug "Engine action queue saturated, rejecting importBlock", | ||
| queueLen = c.queue.len, maxSize = MaxQueueSize |
There was a problem hiding this comment.
Why log a constant? Is there an intention to change this to be variable in the future?
There was a problem hiding this comment.
No, these are only for testing for now
Mostly for me to detect scenarios where this condition is occurring
Would be removed in the final version
| await c.queue.addLast(item) | ||
| if c.queue.full: | ||
| debug "Engine action queue saturated, rejecting forkChoice", | ||
| queueLen = c.queue.len, maxSize = MaxQueueSize |
There was a problem hiding this comment.
Likewise logging a constant.
|
2 participants
An attempt to improve the engineAPI performance. The following changes have been done
Changes
validateVersionedHashedprocessQueuetxRecordsinstead of re-RLP-hashingAfter a block is processed, forked_chain loops over all transactions and calls computeRlpHash(tx) for every one — i.e. re-RLP-encodes and hashes each tx. These hashes were already computed during RLP decode in ethBlock(payload, .... For a 150-tx block that's ~150 × ~20µs ≈ 3ms of wasted work per payload, on the critical path.
When the FC action queue is at MaxQueueSize=128, queueImportBlock and queueForkChoice call await c.queue.addLast(item) which suspends the caller until space frees up. Under burst load the CL sees unbounded tail latency rather than a clean SYNCING response, and the CL will eventually time out.