# QiOi: Performance Isolation for Hyperledger Fabric
## 4 Design and Implementation
### QiOi Algorithm  
As shown in Algorithm 1, the QiOi algorithm is based on proportional control. In other words, the _CPU share_ (\(S\)) is proportionally calculated depending on the difference between the isolation threshold and actual throughput (\(CPU_{diff}\)). Note that \(S_{default}\) is default _CPU share_. If the actual throughput is lower than the isolation threshold, the _CPU share_ of orderers and peers is increased to improve throughput to the isolation threshold. Otherwise, the value of the previous _CPU share_ is sustained. For example, if the isolation threshold and the actual throughput are 500 tps and 400 tps, respectively, the QiOi controller detects performance interference because the actual throughput is below the isolation threshold. The QiOi controller calculates the value of the next _CPU share_ (\(S_{next}\)) to be 1024 + 1024 \(\times\)\(k\)\(\times\)\(\frac{100}{500}\). Note that the QiOi algorithm works on both orderers and peers.  
```
\(T\): Isolation threshold \(A\): Actual throughput \(S\): CPU share of orderers and peers \(diff=|T-A|\) if\(diff>0\)then \(CPU_{diff}=S_{default}\times k\times\frac{diff}{T}\) \(S_{next}=S_{default}+CPU_{diff}\); else \(S_{next}=S_{prev}\);  return \(S_{next}\)
```  
**Algorithm 1**QiOi algorithm.  
The value of \(k\) is an adjustable parameter that affects the rate of the _CPU share_ adjustment. As the \(k\) value increases, the _CPU share_ changes rapidly. For a small \(k\) value, the scheduling delay of the orderers and peers may not minimize effectively. For a large \(k\) value, the _CPU share_ of orderers and peers can easily become significantly larger than that of other Fabric components, which may increase the scheduling delay of other components. Therefore, it is necessary to find a proper \(k\) value providing performance isolation more effectively.  
To investigate the impact of the value of \(k\), we conduct experiments with the same setting used in Section 3. The number of sysbench containers is eight and smallbank chaincode takes about 15 seconds to execute transaction proposals. Figure 5(a) shows Fabric throughput (\(y\)-axis) over time (\(x\)-axis) when the value of \(k\) is changed. When the value of \(k\) is 4, Fabric throughput increases by 14% (from 533 tps to 607 tps) compared to throughput without QiOi. Figure 5(b) depicts the _CPU share_ of orderers and peers (\(y\)-axis) over time (\(x\)-axis) when the value of \(k\) is changed. By the QiOi algorithm, the _CPU share_ of orderersand peers becomes high compared with other processes that have default _CPU share_ (1024), so CFS allocates a larger amount of _time slice_ to them and schedules more frequently. Based on these results, we empirically determined the value of \(k\) and set it to 4. Figure 7 compares the average scheduling delay of Fabric components among without sysbench containers and QiOi (_Alone_), without QiOi (_Together_), and with QiOi (_Together_ w/_QiO_). As a result, their scheduling delay in _Together_ w/_QiOi_ is decreases by 31% (peers) and 58% (orderers), respectively, compared to those of _Together_, which means that performance interference is mitigated. On the other hand, the _CPU share_ of chaincodes keeps the default value, which is lower than that of orderers and peers. Therefore, the scheduling frequency and the amount of time slice decrease. For this reason, the scheduling delay of chaincodes increases from 0.19 ms (_Together_) to 0.24 ms (_Together_ w/_QiO_). Note that Table 4 depicts throughput of sysbench containers depending on the value of \(k\). _Baseline_ indicates the throughput of sysbench containers before applying QiOi. The throughput of sysbench containers drops by 1.2% on average, and QiOi does not sacrifice throughput of sysbench containers.