## 6 Performance Analysis
### Performance Metrics and Benchmarks  
**Performance Metrics.** We ran each test experiment independently, utilizing Caliper's workload modules to construct and send transactions. Three performance metrics of our implemented scheme were then recorded and analyzed to determine its applicability and scalability:  
Figure 4: Deployment model of Hyperledger Caliper. Caliper generates and sends a set number of transactions at a defined send rate to the blockchain. In each run of Caliper, these transactions all represent the same type of transaction, as defined by our developed smart contract (read or write). When Caliper finishes one job, another can be started to simulate another type of transaction. (Author’s own processing).  
* _Transaction Throughput._ This metric is used to show the rate at which valid transactions are committed by our blockchain network, measured in transactions per second (tps). As emphasized by the Performance and Scalability Working Group (PSWG) in [41], this metric determines the rate at which transactions are committed across the entire blockchain network, not just at a single node. This helps to provide more accurate details of the experiment as, for a transaction to be functional across the network, it must be reflected by every node. A high tps value indicates that the widespread implementation of our proposed scheme is viable, enabling a large-scale participation of voters in the election. Conversely, a low tps would increase the time required for a significant number of voters to participate in the election.
* _Transaction Latency._ This metric, computed as transaction confirmation time at network threshold less the submit time of the transaction, demonstrates the time taken for a transaction to be usable across the network. Measuring transaction latency across all nodes of the network ensures a more realistic timing evaluation that reflects the true latency experienced by all users, rather than just the voter.
* _Error Rate._ This is the rate at which submitted transactions are rejected or dropped. The error rate is computed as the number of failed transactions divided by the number of sent transactions. This metric gives an accurate way to determine the maximum operational stress our scheme can handle without fault. Note that while error rate approaches zero in ideal conditions, we assume that ideal conditions are impracticable at large scales due to the distributed architecture of Hyperledger Fabric.  
**Use Cases and benchmarks.** Based on the aforementioned metrics, three different experiments are used to evaluate and analyze the efficacy of the proposed scheme. These use cases are shown in Table 2 and they are described in detail as follows:  
* _Experiment I_ shows varying transaction rates' impact on our scheme's throughput and latency to show the scheme's ability to process transactions when receiving varying amounts of transactions. This simulates the impact of multiple voters using the scheme concurrently.
* _Experiment II_ analyzes the varying of total transactions' impact on the throughput and latency at differing transaction send rates to show the scheme's scalability. This demonstrates the scheme's ability to handle elections involving differing scales of total voters.
* _Experiment III_ shows the error rate due to varying total transactions and transaction send rates.  
For each of the use cases, we tested the main functions of our scheme's functions, namely GetBallot and CastVote. The GetBallot function reads the ledger and returns the ballot associated with a specific voter. The CastVote function generates a new ballot for the voter to use in the election and writes the ballot to our blockchain with the voter's choices.