You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Performance stats are computed by each node, based on the node own performance.
For nodes that are running in sync with the rest of the network, node stats match network stats close enough.
But when a node is catching up with the rest of the network, it might be reporting stats that could deviate from the rest of the network performance.
For example, the number of transactions is computed based on the number of transactions in blocks a given node has processed in the last 60 seconds.
When the node is running in sync with the rest of the network, this number will show the network performance.
When the node is catching up, this number will show the node performance.
Ideally, it would be great to show both numbers at all times: one set of stats for the network, and one for the node.
But, for now, we only report the node stats.
If one wants to monitor specific a given node, they are in luck.
If one wants to see the network performance, they need a node that is in sync.
This is a follow-up to a discussion in #29159.
Specifically these comments:
Add minContextSlot to getRecentPerformanceSamples().
It specifies a minimum slot that the node have already processed, in order to return a successful response.
By choosing the target slot to be close to the tip of the chain, the caller can ensure that the node is reasonably up-to-date.
The text was updated successfully, but these errors were encountered:
ilya-bobyr
changed the title
getRecentPerformanceSamples(): Filter to return results since a certain slotgetRecentPerformanceSamples(): Filter to return results since a certain slot only
Jan 18, 2023
Problem
Performance stats are computed by each node, based on the node own performance.
For nodes that are running in sync with the rest of the network, node stats match network stats close enough.
But when a node is catching up with the rest of the network, it might be reporting stats that could deviate from the rest of the network performance.
For example, the number of transactions is computed based on the number of transactions in blocks a given node has processed in the last 60 seconds.
When the node is running in sync with the rest of the network, this number will show the network performance.
When the node is catching up, this number will show the node performance.
Ideally, it would be great to show both numbers at all times: one set of stats for the network, and one for the node.
But, for now, we only report the node stats.
If one wants to monitor specific a given node, they are in luck.
If one wants to see the network performance, they need a node that is in sync.
This is a follow-up to a discussion in #29159.
Specifically these comments:
Proposed Solution
Add
minContextSlot
togetRecentPerformanceSamples()
.It specifies a minimum slot that the node have already processed, in order to return a successful response.
By choosing the target slot to be close to the tip of the chain, the caller can ensure that the node is reasonably up-to-date.
The text was updated successfully, but these errors were encountered: