Skip to content

Conversation

@ElFantasma
Copy link
Contributor

Motivation
Noticed that random key creation for FindNode messages was consuming a lot of CPU:
image

Description
So, instead of creating a new key on each message, we create a FindNode message on every lookup cycle, and encode it a single time to send to all peers. It removes some randomness but gains in performance. In any case, next lookup cycle will create a new key.

New flamegraph:
image

Tested on mainnet to see if it reduced peer finding performance, and it took 3' 24'' to find 50 peers

2025-10-24T18:48:42.213697Z  INFO ethrex_p2p::network: P2P Snap Sync:
elapsed: 00h 03m 23s 00ms
50 peers.
Current step: Downloading Headers

and 13' 43'' to reach the 100 peers limit:

2025-10-24T18:59:02.280007Z  INFO ethrex_p2p::network: P2P Snap Sync:
elapsed: 00h 13m 43s 00ms
100 peers.
Current step: Downloading Headers
``` 

@ElFantasma ElFantasma requested a review from a team as a code owner October 24, 2025 19:22
@github-actions github-actions bot added L1 Ethereum client performance Block execution throughput and performance in general labels Oct 24, 2025
@github-actions
Copy link

Lines of code report

Total lines added: 0
Total lines removed: 1
Total lines changed: 1

Detailed view
+-----------------------------------------------+-------+------+
| File                                          | Lines | Diff |
+-----------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/discv4/server.rs | 482   | -1   |
+-----------------------------------------------+-------+------+

@github-project-automation github-project-automation bot moved this to In Review in ethrex_l1 Oct 27, 2025
@edg-l edg-l enabled auto-merge October 27, 2025 08:29
@edg-l edg-l disabled auto-merge October 27, 2025 08:29
@github-actions
Copy link

github-actions bot commented Oct 27, 2025

Benchmark Block Execution Results Comparison Against Main

Command Mean [s] Min [s] Max [s] Relative
base 77.068 ± 0.175 76.779 77.360 1.00
head 77.485 ± 0.164 77.219 77.785 1.01 ± 0.00

@ElFantasma ElFantasma added this pull request to the merge queue Oct 27, 2025
Merged via the queue into main with commit 8b0e2b8 Oct 27, 2025
29 checks passed
@ElFantasma ElFantasma deleted the improve_handshake branch October 27, 2025 14:35
@github-project-automation github-project-automation bot moved this from In Review to Done in ethrex_l1 Oct 27, 2025
@github-project-automation github-project-automation bot moved this from Todo to Done in ethrex_performance Oct 27, 2025
iovoid pushed a commit that referenced this pull request Oct 27, 2025
**Motivation**
Noticed that random key creation for FindNode messages was consuming a
lot of CPU:
<img width="1860" height="563" alt="image"
src="https://github.com/user-attachments/assets/9d823161-6013-41fe-94b1-008803edb353"
/>

**Description**
So, instead of creating a new key on each message, we create a FindNode
message on every lookup cycle, and encode it a single time to send to
all peers. It removes some randomness but gains in performance. In any
case, next lookup cycle will create a new key.

New flamegraph:
<img width="1854" height="539" alt="image"
src="https://github.com/user-attachments/assets/d2b42609-e178-4ec7-a1a7-31230926c06e"
/>

Tested on mainnet to see if it reduced peer finding performance, and it
took 3' 24'' to find 50 peers
```
2025-10-24T18:48:42.213697Z  INFO ethrex_p2p::network: P2P Snap Sync:
elapsed: 00h 03m 23s 00ms
50 peers.
Current step: Downloading Headers
```
and 13' 43'' to reach the 100 peers limit:
```
2025-10-24T18:59:02.280007Z  INFO ethrex_p2p::network: P2P Snap Sync:
elapsed: 00h 13m 43s 00ms
100 peers.
Current step: Downloading Headers
``` 

---------

Co-authored-by: Edgar <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

L1 Ethereum client performance Block execution throughput and performance in general

Projects

Status: Done
Archived in project

Development

Successfully merging this pull request may close these issues.

4 participants