lighthouse icon indicating copy to clipboard operation
lighthouse copied to clipboard

Published 20 hours ago • verified publisher icon sigp

Optimise HTTP validator lookups

Open michaelsproul opened this issue 2 years ago • 1 comments

Issue Addressed

While digging around in some logs I noticed that queries for validators by pubkey were taking 10ms+, which seemed too long. This was due to a loop through the entire validator registry for each lookup.

Proposed Changes

Rather than using a loop through the register, this PR utilises the pubkey cache which is usually initialised at the head*. In case the cache isn't built, we fall back to the previous loop logic. In the vast majority of cases I expect the cache will be built, as the validator client queries at the head where all caches should be built.

Additional Info

*I had to modify the cache build that runs after fork choice to build the pubkey cache. I think it had been optimised out, perhaps accidentally. I think it's preferable to have the exit cache and the pubkey cache built on the head state, as they are required for verifying deposits and exits respectively, and we may as well build them off the hot path of block processing. Previously they'd get built the first time a deposit or exit needed to be verified.

I've deleted the unused map_state function which was obsoleted by map_state_and_execution_optimistic.

michaelsproul avatar Sep 09 '22 05:09 michaelsproul

Here's some performance info from some of our Goerli nodes with thousands of inactive validator keys:

speedup

This is the time required for the VC to update all its validator indices from the BN, which drops from 110s to 83s on one VC (-25%) and from 29s to 14s on the other (-51%).

We can see that the underlying time that the BN is spending on the request is even more greatly reduced. Before running this PR the times are in the 2.5-6ms range, and afterwards are in the 50-250us range. Before:

Sep 09 06:48:21.113 DEBG Processed HTTP API request method: GET, path: /eth/v1/beacon/states/head/validators/0xa9dfac8705467d09bdf4db8e68cf6ef54e45294c432b180796634777829704429444d0b28eeed4a66a770bf3f1a104d2, status: 404 Not Found, elapsed: 2.298924ms

After:

Sep 09 06:52:33.637 DEBG Processed HTTP API request method: GET, path: /eth/v1/beacon/states/head/validators/0xa9dfac8705467d09bdf4db8e68cf6ef54e45294c432b180796634777829704429444d0b28eeed4a66a770bf3f1a104d2, status: 404 Not Found, elapsed: 58.289µs

That's a 10-50x reduction (at least -90%).

michaelsproul avatar Sep 09 '22 05:09 michaelsproul

cheers

@deauna, this review looks a lot like engagement farming to me and I will ban your account from this repository if it persists. I apologise sincerely if I've read this wrong.

paulhauner avatar Sep 28 '22 05:09 paulhauner

Sweet!

bors r+

michaelsproul avatar Oct 15 '22 22:10 michaelsproul

Pull request successfully merged into unstable.

Build succeeded:

bors[bot] avatar Oct 16 '22 00:10 bors[bot]