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 2 commits
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
29 changes: 29 additions & 0 deletions book/src/performance-metrics.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# 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 banking stage maintains a count of transactions that it processed.
The dashboard displays the count averaged over 2 second period in the TPS time series
graph. The dashboard also shows per second mean, maximum and total TPS as a running
counter.

## Confimation Time

Each validator node maintains a list of active ledger forks that are visible to the node.
A fork is considered to be frozen when the node has received and processed all entries
corresponding to the fork. A fork is considered to be confirmed when it receives cumulative
supermajority vote, and when one of its children forks is frozen.

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.