# Improving Performance of Key-Value Stores for High-Performance Storage Devices
## 5 Evaluation
### Performance Results  
Figure 4 illustrates the performance of RocksDB with both the existing and proposed schemes on two different machines. As depicted, the proposed scheme improves RocksDB's performance by up to 16% across a range of thread counts, from 1 to 16, on both machines. Specifically, on machine A, the proposed scheme improves performance by 9%, 15%, 15%,  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline benchmarks & fillrandom \\ \hline num & 625,000 \\ \hline key\_size & 16 \\ \hline value\_size & 16,384 \\ \hline use\_direct\_io\_for\_flush\_and\_compaction & true \\ \hline use\_direct\_reads & true \\ \hline compression\_type & none \\ \hline compression\_ratio & 1 \\ \hline max\_background\_flushes & 1 \\ \hline max\_background\_compactions & 1, 2, and 4 \\ \hline threads (changing) & 1 (default), 2, 4, 8, 16 \\ \hline \hline \end{tabular}
\end{table}
Table 1: Evaluation parameters.  
\begin{table}
\begin{tabular}{c c c} \hline \hline  & **Machine A** & **Machine B** \\ \hline \multirow{2}{*}{CPU} & Intel Xeon E5-2620 v4 & Intel Xeon Silver 4314 \\  & (2-way, 16 cores) & (2-way, 32 cores) \\ \hline RAM & 32 GB & 64 GB \\ \hline Storage & Samsung 960 PRO M.2 512 GB & Intel SSD DC P4510 4 TB \\ \hline \hline \end{tabular}
\end{table}
Table 2: Machine specifications.  
10%, and 11% when 1, 2, 4, 8, and 16 threads are allocated for foreground I/O operations, respectively. On machine B, the proposed scheme yields performance improvements of 9%, 15%, 16%, 13%, and 13% for the same thread allocations.  
The performance gains result from utilizing idle computing resources to participate in I/O operations rather than merely waiting for the completion of background jobs. By leveraging threads originally scheduled for foreground I/O operations, the thread allocated to background jobs can concentrate on processing data fetched from the read buffer during compaction. This approach reduces the time required, as the thread responsible for the background job can read data from a prefetched memory region instead of directly from the storage device. Additionally, the proposed scheme not only accelerates overall processing performance but also reduces lock contention among threads attempting to become the leader during foreground I/O operations. However, as shown in the figure, the performance gains diminish when using 8 or 16 threads compared to 2 or 4 threads on both machines. Increasing the number of threads does not yield proportional performance improvements. This is because, as the thread count increases, the overhead associated with acquiring locks during foreground I/O operations and becoming the leader thread also increases.  
Furthermore, to assess the effectiveness of the proposed scheme with an increasing number of background threads, we measure performance by varying the max_background_compactions parameter to 2 and 4. Since our scheme is designed to perform concurrent read operations on files required for compaction, we focused on adjusting the number of threads allocated to compaction jobs. Figure 5 presents the performance results with varying numbers of background threads. The results indicate that the proposed scheme improves performance by accelerating the background compaction job through concurrent reading of target files while reducing delays during foreground I/O operations.  
In summary, our evaluation demonstrates that the proposed scheme can effectively improve the performance of KV stores when a high number of threads are used in conjunction with emerging fast storage devices.  
Figure 4: Performance of KV store with the original and proposed schemes on different machines.