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
Total Rewards Paid for the network is now returned in a single GET /v1/home call instead of N requests to GET /v1/rewards/bakers/{address}. The dashboard can read networkRewardsData from home and stop calling getNetworkRewardSummary(validators, limit).
Changes
GET /v1/home response includes networkRewardsData:
cycleRewardSummaries — optional array of per-cycle breakdown (when requested).
Aggregation: One SQL query over BakerCycles (all cycles), grouped by cycle; sums of block rewards, endorsement rewards, and block fees.
Optional cycleRewardSummaries: Query param can be re-added to include the per-cycle array; when omitted, the array is not returned to keep the default response small.
The reason will be displayed to describe this comment to others. Learn more.
This seems like a heavy computation that wouldn't scale with the growing amount of bakers. Did you stress test /home before and after the addition? It may cause a spike in cpu/mem so I want to be sure that it's harmless
The reason will be displayed to describe this comment to others. Learn more.
There are several points:
The BakerCycles table does not contain many records, about 1,000 now, and expected to grow to 100,000+ (which is still not a large volume).
This query is not executed on every /home request; it runs only during UpdateAsync() updates, once per UpdatePeriod levels. Therefore, I don’t see any issues with this query, as it places only a moderate load on the database.
I ran a quick test of the query itself using EXPLAIN, and also tested the method in a loop. We’ll need to set up an environment to perform proper load testing in a cluster on a real machine, but that can be done later.
BakerCycles GROUP BY Cycle (cycle reward summaries)
Runs: 5000
Min: 0.8 ms
Max: 6.1 ms
Avg: 1.0 ms
Median: 0.9 ms
p95: 1.5 ms
p99: 2.3 ms
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Total Rewards Paid for the network is now returned in a single
GET /v1/homecall instead of N requests toGET /v1/rewards/bakers/{address}. The dashboard can readnetworkRewardsDatafrom home and stop callinggetNetworkRewardSummary(validators, limit).Changes
GET /v1/homeresponse includesnetworkRewardsData:totalRewardsAllTime,totalBlockRewards,totalEndorsementRewards,totalBlockFeescyclesCount,averageRewardsPerCyclecycleRewardSummaries— optional array of per-cycle breakdown (when requested).Aggregation: One SQL query over
BakerCycles(all cycles), grouped by cycle; sums of block rewards, endorsement rewards, and block fees.Optional
cycleRewardSummaries: Query param can be re-added to include the per-cycle array; when omitted, the array is not returned to keep the default response small.