\chapter{分散木構造データーベース Jungle の評価}
前章では Jungle における分散データベースの詳細な実装について述べた.
本章では実装を行った Jungle に対して Cassandra との性能比較を行い評価をする.
性能比較の為に簡易な掲示板プログラムを Jungle と Cassandra それぞれに作成した.
複数のノードに繋がっている状態においても性能を測りたいため, 学科提供する
VMWare の並列環境を利用する. また, 我々の研究室が利用しているブレードサーバ
上で動いている KVM もノードとして利用する.

\section{実験方法}
実験は同じ機能を提供している簡易掲示板プログラムを Jungle と Cassandra それぞれで
動かし, HTTPリクエストにより負荷をかけて行う.
レスポンスが帰ってくるまでの時間をはかる.

また, 実験は2つ行う.
まず行う実験は, 複数のノードで起動してるうちの1つのノードに負荷をかける方法である.
これはノードの数に比例してレスポンスが遅くなっていないか確かめるためである.
\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.70]{figures/jungle_experiment.pdf}
    \caption{複数起動中のJungle の1ノードへの負荷}
    \label{fig:jungle_exp}
  \end{center}
\end{figure}

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.70]{figures/cas_experiment.pdf}
    \caption{複数起動中のCassandra の1ノードへの負荷}
    \label{fig:cas_exp}
  \end{center}
\end{figure}

次に行う実験は複数のノードに対し複数のクライアントから負荷をかける方法である.
それぞれ大量のHTTPリクエストをだし, 全てのリクエストの処理にかかる時間を測定する.

クライアントの数に比例してノードを増やすことでレスポンスを維持できるか
スケーラビリティを調べるためである.
\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.70]{figures/clients_request_servers.pdf}
    \caption{複数のクライアントから複数のノードへの負荷}
    \label{fig:clients_servers}
  \end{center}
\end{figure}

\subsection{weighttp}
最初の実験で1つのノードに負荷をかけるプログラムはウェブサーバの測定ツールであるweighttpを使用する.
weighttpは総リクエスト数, 同時接続数, ネイティブスレッド数をオプションとして指定することができる.


\subsection{掲示板プログラム}
今回使用する掲示板プログラムは組み込み用ウェブサーバであるJettyをフロントエンドとして利用し, バックエンド
に Jungle と Cassandra を利用している.


\subsection{実験環境}

\subsubsection{ノードを実行させるサーバの仕様}
使用するVMWareとKVMのクラスタの使用を以下に示す.
クラスタは仕様を表\ref{tab:cluster_spec_vmware}と表\ref{tab:cluster_spec_kvm}に示す.

\begin{table}[!htbp]
\caption{ノードを実行させるVMWareクラスタの仕様}
\label{tab:cluster_spec_vmware}
\begin{center}
\begin{tabular}{|c||c|} \hline
名前 & 概要 \\ \hline \hline
CPU & Intel(R) Xeon(R) CPU X5650@2.67GHz \\ \hline
Memory & 8GB \\ \hline
OS & CentOS 5.8 \\ \hline
HyperVisor & VMWare ESXi \\ \hline
\end{tabular}
\end{center}
\end{table}

\begin{table}[!htbp]
\caption{ノードを実行させるKVMクラスタの仕様}
\label{tab:cluster_spec_kvm}
\begin{center}
\begin{tabular}{|c||c|} \hline
名前 & 概要 \\ \hline \hline
CPU & Intel(R) Xeon(R) CPU X5650@2.67GHz \\ \hline
Memory & 8GB \\ \hline
OS & CentOS 5.8 \\ \hline
HyperVisor & KVM \\ \hline
\end{tabular}
\end{center}
\end{table}

\subsubsection{1台に負荷をかけるブレードサーバの仕様}
最初の実験で負荷をかける側としてブレードサーバを使用する.
ブレードサーバの仕様を表\ref{tab:server_spec_1}に示す

\begin{table}[!htbp]
\caption{}
\label{tab:server_spec_1}
\begin{center}
\begin{tabular}{|c||c|} \hline
名前 & 概要 \\ \hline \hline
CPU & Intel(R) Xeon(R) CPU X5650@2.67GHz \\ \hline
物理コア数 & 12 \\ \hline
論理コア数 & 24 \\ \hline
Memory & 132GB \\ \hline
OS & Fedora 16 \\ \hline
JavaVM & Java(TM) SE Runtime Environment (build 1.7.0-b147) \\ \hline
\end{tabular}
\end{center}
\end{table}



\subsubsection{サーバの環境}
HTTPによりノードに負荷を掛ける場合気をつけることがある.
それはサーバの設定により最大コネクション数や開くことのできるファイル記述子の数に制限がかかっていることである.
この2つの値はデフォルトでは小さなものとなっており, そのままではカーネル
の設定がネックとなったベンチマーク結果がでる可能性がある.
そこで次のようにコマンドを実行することでコネクション数の制限を増やすことができる.
\begin{lstlisting}[frame=lrbt,label=src:maxconn_up,caption=コネクション数を増やす,numbers=left]
% sudo sysctl -w net.core.somaxconn=10000
\end{lstlisting}
ファイル記述子の制限を増やす場合は次のコマンドを実行する
\begin{lstlisting}[frame=lrbt,label=src:max_up_filedisc,caption=ファイル記述子の制限を増やす,numbers=left]
% ulimit -n 10000
\end{lstlisting}

\section{実験結果1}


\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{figures/read_bench.pdf}
    \caption{読み込みベンチマーク結果}
    \label{fig:read_cassandra}
  \end{center}
\end{figure}


\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{figures/write_bench.pdf}
    \caption{書き込みベンチマーク結果}
    \label{fig:write_cassandra}
  \end{center}
\end{figure}

\section{実験結果2}