This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "". The branch, master has been updated via e130299958e7fbe8bb606275c77899c779f30038 (commit) from 43ce85cbe2bcf4d24577fe926881180d66225fc7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit e130299958e7fbe8bb606275c77899c779f30038 Author: Phil Carns <[email protected]> Date: Tue Mar 17 20:38:49 2015 -0400 update performance results ----------------------------------------------------------------------- Summary of changes: .../localstore-report.tex | 80 +++++++++---------- 1 files changed, 38 insertions(+), 42 deletions(-) Diff of changes: diff --git a/reports/triton-localstore-convergence/localstore-report.tex b/reports/triton-localstore-convergence/localstore-report.tex index 2370da5..b752020 100644 --- a/reports/triton-localstore-convergence/localstore-report.tex +++ b/reports/triton-localstore-convergence/localstore-report.tex @@ -200,22 +200,19 @@ stored in Triton. \subsection{Preliminary Evaluation} -\textcolor{red}{TODO: consider coming back and doing multithreaded baseline -measurements as well, maybe both with linear and random I/O?} - \begin{figure}[t] \centering - \subfigure[Recordstore (RS)]{ + \subfigure[16x concurrency]{ \centering - \includegraphics[width=0.45\textwidth]{figs/recordstore-ssd/recordstore-ssd.pdf} - \label{fig:rs-perf} + \includegraphics[width=0.45\textwidth]{figs/all-ssd/1way-ssd.pdf} + \label{fig:1w-perf} } - \subfigure[HOSS]{ + \subfigure[no concurrency]{ \centering - \includegraphics[width=0.45\textwidth]{figs/hoss-ssd/hoss-ssd.pdf} - \label{fig:hoss-perf} + \includegraphics[width=0.45\textwidth]{figs/all-ssd/16way-ssd.pdf} + \label{fig:16w-perf} } - \caption{Streaming write performance at the Recordstore and HOSS component level on an Intel 730 series SSD using direct I/O and + \caption{Streaming write performance on an Intel 730 series SSD using direct I/O and synchronizing each operation to disk.} \label{fig:perf} \end{figure} @@ -230,44 +227,43 @@ underlying storage device. The write access size was varied from 4 KiB to 4 MiB. All tests were performed using direct I/O (to improve performance for high performance storage devices), and each I/O operation was synchronized to disk before being reported as complete (to evaluate durable write -performance). +performance). We measured performance in two scenarios: one with no concurrency, using sequential +writes, and one with 16-way concurrency using sequentially issued writes. -The results of these experiments are shown in Figure~\ref{fig:perf}. -Linux \texttt{dd} command line utility performance is also shown for -comparison. \texttt{dd} was configured as follows: +As a baseline for comparison we used the \texttt{dd} and and \texttt{fio} benchmark utilities. The +\texttt{dd} utility is not capable of issuing concurrent I/O and thus is not shown in the 16-way +concurrency example. \texttt{dd} was configured as follows: \begin{verbatim} dd if=/dev/zero of=/tmp/1.dat bs=$SIZE count=50000 oflag=direct,dsync \end{verbatim} -Each configuration was executed and measured for 10 seconds. In the +\texttt{fio} was configured as follows: + +\begin{verbatim} +fio --ioengine=psync --iodepth=1 --group_reporting --numjobs=$CONCURRENCY --direct=1 --thread \ +--offset_increment=$SIZE --filename=fio.dat --name=test --readwrite=write --blocksize=$SIZE \ +--runtime=10 --fdatasync=1 --unlink=1 --size=4G --overwrite=0 +\end{verbatim} + +Each benchmark was executed and measured for 10 seconds. In the case of \texttt{dd}, the transfer was halted after 10 seconds by sending a signal to the -benchmark process, while the Recordstore -benchmark automatically halted execution after 10 seconds. -All writes were issued sequentially starting from file offset 0 or record -index 0 (for \texttt{dd} file access and Recordstore object access, -respectively). - -Two Recordstore examples are shown in Figure~\ref{fig:rs-perf}: one that -issued one operation at a time, and one that issued up to 16 concurrent -operations using Aesop pbranches. Recordstore is optimized for the -latter scenario, and the underlying Aesop concurrency model allows it to -saturate available storage bandwidth. As a result, it exceeds the -baseline \texttt{dd} performance by a wide margin at each access size. -The non-concurrent workload, in contrast, does not match baseline -\texttt{dd} performance. We believe that performance for this workload could be -improved using \texttt{pthread} optimizations to reduce thread latency, -however. - -Figure~\ref{fig:hoss-perf} repeats the same experiment using the HOSS API -layer atop the Recordstore rather than using the Recordstore directly. -This API layer presents a full object interface with versioning and -indexing. It's performance trends largely match that of the direct -Recordstore write benchmark. The most noticeable discrepancy relative to -the Recordstore performance is in small (32 KiB or smaller) write access -without concurrency. Berkeley DB access latency is a significant factor -in response time for small writes, but this effect is mitigated by improved -utilization under concurrent workloads. +benchmark process, while the HOSS, Recordstore, and fio +benchmarks automatically halted execution after 10 seconds. + +The sequential results with no concurrency are shown in Figure~\ref{fig:1w-perf}. We see that +\texttt{dd} and \texttt{fio} perform similarly, reaching a peak of over 250 MiB/s. The recordstore +performance does not match the baseline performance due to multithreading overhead. Because it is +optimized for concurrent I/O activity, it always uses threads to perform I/O operations, while the +\texttt{dd} and \texttt{fio} benchmarks do not. The HOSS benchmark performs slightly slower than +Recrodstore by itself due to the additional latency of storing version and index metadata on each +operation. + +The sequential results with 16-way concurrency are shown +in Figure~\ref{fig:16w-perf}. Unlike the sequential case, the +Recordstore and HOSS optimizations and Aesop concurrency allow it +to match the baseline multithreaded \texttt{fio} performance despite +the additional record-granular versioning and indexing functionality. Recordstore and HOSS performance could be improved via thread tuning and Berkeley DB access optimization. Both components already @@ -275,7 +271,7 @@ perform well for highly concurrent workloads, however. We also note that we expect to achieve the same bandwidth for non-sequential access as well due to the log-structured nature of the Recordstore file module. We focused on sequential access patterns in these preliminary experiments for simplicity -and to facilitate comparison to the sequential \texttt{dd} utility. +and to facilitate comparison to the baseline \texttt{dd} and \texttt{fio} benchmarks. \section{Conclusions} hooks/post-receive --