Read Latency = Time when response received – submit time
Read latency is the time between when the read request is submitted and when the reply is received.
Read Throughput
Read Throughput = Total read operations / total time in seconds
Read throughput is a measure of how many read operations are completed in a defined time period, expressed as reads per second (RPS). This metric may be informative, but it is not the primary measure of blockchain performance. In fact, systems will typically be deployed adjacent to the blockchain to facilitate significant reading and queries.
Transaction Latency
Transaction Latency = (Confirmation time @ network threshold) – submit time
Transaction Latency is a network-wide view of the amount of time taken for a transaction’s effect to be usable across the network. The measurement includes the time from the point that it is submitted to the point that the result is widely available in the network. This includes the propagation time and any settling time due to the consensus mechanism in place.
To account for both of those factors and give the network-wide view, the delay should be measured using all nodes in the SUT. Eyal et al provide a helpful definition for the amount of time for a percentage of the network to commit the transaction1, which we have simplified somewhat here. The latter part of this definition, the percentage of the network, is most significant for consensus protocols like PoW. In such systems a threshold like 90% may be desired, whereas in a non-probabilistic protocol like PBFT 100% is the only meaningful threshold.
This metric is computed per transaction, but in most cases reports should provide various statistics over all transactions like the average, high, low, and standard deviations.
Transaction Throughput
Transaction Throughput = Total committed transactions / total time in seconds @ #committed nodes
Transaction throughput is the rate at which valid transactions are committed by the blockchain SUT in a defined time period. Note that this is not the rate at a single node, but across the entire SUT, i.e. committed at all nodes of the network. This rate is expressed as transactions per second (TPS) at a network size.
Remember that the total number of invalid transactions should be subtracted from the total transactions to yield the total committed transactions. See Appendix A for further discussion of how to calculate different examples of latency.
Is your proposal related to a problem?
ref to previous PSWG white paper with PSB
Describe the solution you'd like
won't do
base on a specific tx from jaeger for Read Throughputbase on a specific tx from jaeger for Transaction ThroughputTBD
ref to https://www.hyperledger.org/learn/publications/blockchain-performance-metrics
Read Latency
Read Latency = Time when response received – submit time
Read latency is the time between when the read request is submitted and when the reply is received.
Read Throughput
Read Throughput = Total read operations / total time in seconds
Read throughput is a measure of how many read operations are completed in a defined time period, expressed as reads per second (RPS). This metric may be informative, but it is not the primary measure of blockchain performance. In fact, systems will typically be deployed adjacent to the blockchain to facilitate significant reading and queries.
Transaction Latency
Transaction Latency = (Confirmation time @ network threshold) – submit time
Transaction Latency is a network-wide view of the amount of time taken for a transaction’s effect to be usable across the network. The measurement includes the time from the point that it is submitted to the point that the result is widely available in the network. This includes the propagation time and any settling time due to the consensus mechanism in place.
To account for both of those factors and give the network-wide view, the delay should be measured using all nodes in the SUT. Eyal et al provide a helpful definition for the amount of time for a percentage of the network to commit the transaction1, which we have simplified somewhat here. The latter part of this definition, the percentage of the network, is most significant for consensus protocols like PoW. In such systems a threshold like 90% may be desired, whereas in a non-probabilistic protocol like PBFT 100% is the only meaningful threshold.
This metric is computed per transaction, but in most cases reports should provide various statistics over all transactions like the average, high, low, and standard deviations.
Transaction Throughput
Transaction Throughput = Total committed transactions / total time in seconds @ #committed nodes
Transaction throughput is the rate at which valid transactions are committed by the blockchain SUT in a defined time period. Note that this is not the rate at a single node, but across the entire SUT, i.e. committed at all nodes of the network. This rate is expressed as transactions per second (TPS) at a network size.
Remember that the total number of invalid transactions should be subtracted from the total transactions to yield the total committed transactions. See Appendix A for further discussion of how to calculate different examples of latency.
Describe alternatives you've considered
(Write your answer here.)
Additional context
N/A
(Write your answer here.) N/A