-
-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: add preHandler hook to fastify #6210
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #6210 +/- ##
=========================================
Coverage 85.63% 85.63%
=========================================
Files 172 172
Lines 14372 14372
Branches 880 880
=========================================
Hits 12308 12308
Misses 2041 2041
Partials 23 23 |
Can't we see the latency between vc-bn already if we look at the Req log from At least in their docs there is a note about the body being undefined, I am not sure though if this implies that it might not yet be fully streamed
In the
Depends on what we wanna measure I think Their docs has a great diagram to show the request lifecycle |
Performance Report✔️ no performance regression detected Full benchmark results
|
no, we can't see the latency between vc-bn right now. The we can see that
yes the body is not streamed when
up until now the most suspected thing is we have |
But looking at the timestamp when the vc send the request and the Req timestamp on the beacon node should be pretty accurate to see the network latency between the vc <> bn. Otherwise I don't see any way how we could measure that, there is no hook before
Yes, this definitely makes sense, just to want to make sure we are looking at the right data In case of these two logs, the time between first and second log is how long it took fastify to parse (
Especially parsing step could be an issue as it's done the main thread which might be busy. |
🎉 This PR is included in v1.14.0 🎉 |
Motivation
There are some delays publishing blocks, in the example below the
publishBlockV2
comes first but get executed the last:I suspect the delay could come from
vc
-bn
latency posting the payload aspublishBlockV2
is the only api with big request bodythis is also caught by
getResponseTime()
api of fastifyDescription
preHandler
hook to fastify to make it clear the delay comes fromvc
-bn
latency or the api handler itself (which contains deserializing the request body + api impl). This hook is called right before our api handler. Log looks like:this should help us separate streaming time + fastify steps from our own handler time