Performance test settings. Before utilising Hyperledger Caliper [11] for conducting a perfor- xxxxx analysis on the prototype, custom benchmark tests had to be created. These tests are set up to initialise the ledger (adding the medical supply), perform the transaction (e.g. requests) and afterwards clear the ledger (deleting the medical supply). All transactions are set to run for a total length of a minute each and have five workers run concurrently invoking the transactions. By setting these with a time limit, information can be gathered on the latency and the number of transactions invoked. Hyperledger Caliper has been run a total of five times where the averages of the measurements were taken and put in table 2. Average results were taken for accuracy reasons, where the total amount of testing runs to be used was done up to five, as otherwise it would become too computationally intensive for the machine it was run on. It should be noted that during testing, due to high load the transactions querying multiple entries from the ledger could not manage to finish in time resulting in time-out errors. Re-running these individually, instead of all at once, was done for it to resolve this issue. Function Name Amount invoked Send Rate Max Latency (s) Min Latency (s) Avg Latency (s) Through put Issue 1,120 18.8 1.14 0.10 0.35 18.8 Request 21,181 358.0 0.08 0.01 0.02 357.0 CancelRequest 22,095 374.4 0.08 0.01 0.02 374.4 ApproveRequest 19,664 333.1 0.11 0.01 0.02 333.1 RejectRequest 22,357 378.8 0.09 0.01 0.02 378.7 CheckHistory 3,549 60.1 0.23 0.02 0.10 60.0 CheckUserHistory 2,945 49.8 0.40 0.03 0.12 49.7 CheckAvailableMedicine 3,270 55.2 0.36 0.03 0.11 55.2 CheckRequestedMedicine 3,181 53.7 0.29 0.03 0.13 53.5 SearchMedicineByName 5,260 53.6 0.22 0.03 0.07 53.3 ChangeStatus 21,242 359.9 0.08 0.01 0.02 359.9 ChangeHolder 21,102 357.6 0.07 0.01 0.02 357.5 Table 2: Average performance results over five runs before the TPM integration Prototype before TPM changes. From table 2 it can be seen that each transaction is relatively fast with the highest latency being around an average of 6.39 seconds. A distinction can be made between transactions that have a high amount of being invoked with lower latency and transactions that are the opposite with a low amount of being invoked and higher latency. This is to be expected as the latter is the type of transaction that queries all entries from the ledger and filters on certain criteria (e.g. on only available medical supply). The Issue transaction i...
