Skip to content
This repository has been archived by the owner on Jan 22, 2025. It is now read-only.

Performance metrics computation methodology #4041

Merged
merged 3 commits into from
Apr 27, 2019
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions book/src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,7 @@
- [Ledger Replication](ledger-replication.md)
- [Secure Vote Signing](vote-signing.md)
- [Staking Delegation and Rewards](stake-delegation-and-rewards.md)
- [Performance Metrics](performance-metrics.md)

- [Anatomy of a Fullnode](fullnode.md)
- [TPU](tpu.md)
Expand Down
25 changes: 25 additions & 0 deletions book/src/performance-metrics.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Performance Metrics

Solana cluster performance is measured as average number of transactions per second
that the network can sustain (TPS). And, how long it takes for a transcation to be
confirmed by super majoring of the cluster (Confirmation Time).
pgarg66 marked this conversation as resolved.
Show resolved Hide resolved

Each cluster node maintains various counters that are incremented on certain events.
These counters are periodically uploaded to a cloud based database. Solana's metrics
dashboard fetches these counters, and computes the performance metrics and displays
it on the dashboard.

## TPS

The leader node's bank maintains a count of transactions that it processed. The dashboard
displays sum of the count for every 2 second period in the TPS time series graph.
pgarg66 marked this conversation as resolved.
Show resolved Hide resolved
The dashboard also shows mean, maximum and total TPS as a running counter.
pgarg66 marked this conversation as resolved.
Show resolved Hide resolved

## Confimation Time

Each validator node maintains a list of active ledger forks that are visible
to the node. Whenever a fork's final tick is registered, the fork is frozen, and
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That’s not correct. The validator confirmation time for a fork is based on the difference when a fork is created and when the first child fork that has a cumulative supermajority vote for the original fork s frozen.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that fork is frozen when there's a cumulative supermajority vote. I don't understand why the child fork has to be frozen?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Frozen right now means that blocktree received all the blobs and the bank processed them. Validator confirmation time for a parent is based on when any descendant of the parent is frozen and that branch has a supermajority conforming the parent. Replay stage doesn’t compute a rolling vote total on incomplete forks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok. that makes sense. I had interpreted your last comment as one of the child fork has to receive supermajority vote. Just to confirm, this is when a fork is considered confirmed:

  1. The fork itself has received cumulative supermajority vote.
  2. One of the child of the fork has been frozen (i.e. received all it's blocks)

considered to be confirmed. The node assigns a timestamp to every new fork, and
computes the time it took to confirm the fork. This time is reflected as validator
confirmation time in performance metrics. The performance dashboard displays the
average of each validator node's confirmation time as a time series graph.