\clearpage
\addcontentsline{toc}{chapter}{付録}
\appendix
\def\thesection{付録\Alph{section}}
\section[　計測環境の構築]{計測環境の構築}
ウェブアプリケーションのベンチマークを行う際, サーバの設定に注意を払う必要がある. 
適切に設定を行わないと, サーバがボトルネックとなってしまい正しい結果が得られない. 
ウェブアプリケーションのベンチマークを行う際の注意点について述べる. 

データを受信したり送信したりするのは OS カーネルである. 
多くの TCP パケットを要求し, 各パケットのサイズが1500バイトといった大きなファイルを提供する場合, 
ウェブアプリケーションというよりOSカーネルのテストになってしまう. 

接続には, HTTP Keep-Alivesを利用する. 
新しい TCP 接続を確立するのはとても遅く, OS カーネルによって行われる. 
毎秒多くの新しい接続を作成するベンチマークを行うと, OSカーネルのテストとなってしまう. 

アプリケーションやOSカーネルが完全にハードウェアを使用できるようにするためにいくつか調整を行う必要がある. 
最初の問題は, ファイル記述子の欠如である. 
デフォルトはプロセスあたり, 1,024 files で非常に貧弱な結果しか得られない. 
ファイル記述子の現在のリミットはソースコード\ref{ulimit} のコマンド取得できる. 

\begin{lstlisting}[label=ulimit, caption=ファイル記述子のリミットの取得]
$ ulimit -aH 
\end{lstlisting}

リミットを変更するには, ソースコード\ref{ulimit2} のコマンドを実行する. 

\begin{lstlisting}[label=ulimit2, caption=ファイル記述子のリミットの設定]
$ sudo sh -c ulimit -HSn 200000
\end{lstlisting}

再起動後も有効にするためには, システムファイルの編集を行う. 

/etc/security/limits.conf へソースコード\ref{limit}の記述を追加する. 

\begin{lstlisting}[label=limit, caption=リミットの設定の追加]
 * soft nofile 200000
 * hard nofile 200000
\end{lstlisting}

次に問題となるのは listenキューの制限である. 
listen キューとは, 保留中のコネクションが繋がれるキューのことである. 
このキューの長さの制限が小さいと, 同時にたくさんのコネクション要求がきた場合, 制限を超えた要求を拒否する. 
listen キューや, その他の設定も含めてベンチマーク用にサーバの設定を変更する. 

/etc/sysctl.conf にソースコード\ref{sysctl}の記述を追加する. 

\newpage
\begin{lstlisting}[label=sysctl, caption=システム設定の変更]
fs.file-max = 5000000
net.core.netdev_max_backlog = 400000
net.core.optmem_max = 10000000
net.core.rmem_default = 10000000
net.core.rmem_max = 10000000
net.core.somaxconn = 100000
net.core.wmem_default = 10000000
net.core.wmem_max = 10000000
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_congestion_control = bic
net.ipv4.tcp_ecn = 0
net.ipv4.tcp_max_syn_backlog = 12000
net.ipv4.tcp_max_tw_buckets = 2000000
net.ipv4.tcp_mem = 30000000 30000000 30000000
net.ipv4.tcp_rmem = 30000000 30000000 30000000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_wmem = 30000000 30000000 30000000    
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
\end{lstlisting}

ファイルを保存後, 設定を反映させるにはソースコード\ref{sysctl2}のコマンドを実行する. 

\begin{lstlisting}[label=sysctl2, caption=設定の反映]
$ sudo sysctl -p /etc/sysctl.conf
\end{lstlisting}

ベンチマークを行う際, 小さなテストでは妥当性が低くなってしまうので注意する. 
TCP/IPのスタックは保守的な方法で動作し, ダウンロード速度に合わせて徐々に速度を増大させるためである. 

また, テストするサーバより遅いベンチマーククライアントを用いると正しい結果は得られない. 
シングルスレッドで稼働したり, Ruby や Python といった低速なベンチマークツールでテストを行うと, 
すべてのテストする対象が同じパフォーマンスを持っているように見えてしまう. 

\subsubsection{weighttp}
ウェブアプリケーションの性能測定には, weighttpを用いる. 
weighttpはWebサーバの性能測定ツールで, マルチコアCPUを使ってテストできる\cite{weighttp}. 
また, livev を使うことで, モダンなポール・システムコールを利用し, 測定性能を向上できるといった特徴を持つ. 
同様の性能測定ツールには, Apache Benchやhttprefが存在するが非力であり, ボトルネックとなってしまうため使用しない. 

weighttp を起動するには, ソースコード\ref{weighttp}のコマンドを入力する. 
\begin{lstlisting}[label=weighttp, caption=weighttpの起動]
$ weighttp -n 1000000 -c 1000 -t 10 -k "http://bldsv12.cr.ie.u-ryukyu.ac.jp:3000"
\end{lstlisting}

起動時には対象のサーバの URL を記述する他に, いくつかのオプションを指定できる. 
\begin{itemize}
 \item n ... HTTP リクエストの総数
 \item c ... 同時に接続するコネクションの数
 \item t ... 作製するネイティブスレッドの数
 \item k ... HTTP Keep-Alives を有効にする
\end{itemize}

\clearpage

\section[　Warp を用いたウェブアプリケーションの構築]{Warp を用いたウェブアプリケーションの構築}
Warp は, 軽量・高速な HTTP サーバである\cite{warp}. 
Haskell の軽量スレッドを活かして書かれている. 
Haskell のウェブフレームワークである Yesod のバックエンドとして用いられており, 現在も開発が続けられている. 

Warp を用いてウェブアプリケーションを構築する方法について説明する. 

% Source Codeは実行可能な状態でsrcに置いてある 
% firstline, lastlineで, どの範囲を表示するか指定できる
\lstinputlisting[label=warp_sample, caption=Warpを用いたウェブアプリケーションの例, firstline=9]{src/warp.hs}

ソースコード \ref{warp_sample}は, URLによって出力する結果を変更するウェブアプリケーションである. 
/hello/worldへアクセスがあった場合は, インクリメントされる counter が表示される. 

\paragraph*{main}
HTTP サーバを起動するには, Warp の run 関数を利用する. 
run 関数は, 利用する Port 番号と, application というリクエストを受けて何かしらのレスポンスを返す関数の2つを引数として受け取る. 

関数型言語では, 関数を第一級オブジェクトとして扱える. 
また, 今回は Haskell のカリー化された関数の特性を利用し, main 内で作成した IORef 型の counter を部分適用させている. 

IORef を用いることで, Haskell で更新可能な変数を扱うことができる. 
参照透過性を失うようにみえるが, Haskell は IO モナドを利用することで純粋性を保っている. 
IORef 自体が入出力を行うわけではなく, 単なる入出力操作の指示にすぎない. 
IO モナドとして糊付けされた単一のアクションに main という名前を付けて実行することで処理系が入出力処理を行う. 

\paragraph*{application 及び routes , findRoute}
application の実装では, routes という関数を独自に定義して, URL によって出力を変更している. 
application に渡されるリクエストはデータ型で様々な情報が含まれている. 
その中のひとつに pathInfo という, URL から hostname/port と, クエリを取り除いたリストがある. 
この情報を routes という関数に渡すことで, routeSetting というリストから一致する URL がないか調べる. 
routeSetting は, URL のリストとレスポンスを返す関数のタプルのリストである. 

\paragraph*{notFound 及び hello}
レスポンスを返す関数は, いくつか定義されている. 
その中で利用されている responseLBS は文字列からレスポンスを構築するためのコンストラクタである. 

\paragraph*{world 及び incCount}
world は, インクリメントされる counter を表示するための関数である. 
IORef 内のデータは直接触ることができないため, incCount 内で atomicModifyIORef を利用してデータの更新を行なっている. 
atomicModifyIORef は, データの更新をスレッドセーフに行うことができる. 
また, responseLBSで構築したレスポンスは, Resource Tというリーソスの解放を安全に行うために使われるモナドに包まれている. 
lift 関数を用いて, incCountの型を持ち上げ調整している. 


プログラムを例にして説明したが, Warp は容易にプログラムに組み込むことができる. 
本研究では, 非破壊的木構造データベース Jungle と Warp を組み合わせて, 掲示板ウェブアプリケーションを開発した.