Mercurial > hg > Papers > 2015 > tatsuki-thresis

comparison chapter7.tex @ 4:3ac8c8d97fea

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
2/16
author tatsuki
date Mon, 16 Feb 2015 17:56:08 +0900
parents 470dc248d615
children b0fd781e3b05
comparison
equal deleted inserted replaced
3:470dc248d615 4:3ac8c8d97fea
34 \label{fig:isActive} 34 \label{fig:isActive}
35 \end{center} 35 \end{center}
36 \end{figure} 36 \end{figure}
37 37
38 isActiveの実行時間は、Indexを使用しない場合は、Personの数が増えると比例して増えていくのに対し、Indexを使用するとPersonの数が増えても実行時間は変わらなかった。 38 isActiveの実行時間は、Indexを使用しない場合は、Personの数が増えると比例して増えていくのに対し、Indexを使用するとPersonの数が増えても実行時間は変わらなかった。
39 この結果より、JungleのIndexは性能が出ることが確認できた。 39 この結果より、JungleのIndexの計算量はO(logn)であることがわかる。
40 40
41 \clearpage 41 \clearpage
42 \section{複数threadからのreadの測定} 42 \section{read\&writeの測定}
43 1秒間Jungleに対して、readを複数Threadから同時に行った際の性能測定を行う 43 1秒間の間Jungleに対し書き込みと、データの検索を同時に行い、Jungleの書き込みがどの程度検索に影響をおよぼすかを調べる。
44 測定には、Jungleが保持しているPerson数は100とし、4.2と同じく関数isActiveを用いた。 44 測定の条件は、Jungleが保持しているPerson数は100、書き込みに1Thread使用し、読み込みを行うThreadは1から12個まで使用する。read関数は実験1と同じく関数isActiveを用いた。
45 実験の結果は図\ref{fig:thread}となる。横軸はJungleに対し、readを行うthread数、縦軸はreadを行った回数を表す。 45 実験の結果は図\ref{fig:thread}となる。横軸はJungleに対し、readを行うthread数、縦軸はreadを行った回数を表す。
46 46
47 \begin{figure}[h] 47 \begin{figure}[h]
48 \begin{center} 48 \begin{center}
49 \includegraphics[bb=0 0 360 252]{fig/readMaltiThread.pdf} 49 \includegraphics[bb=0 0 360 252]{fig/readMaltiThread.pdf}
50 \caption{複数Threadからのread} 50 \caption{read\&writeの測定}
51 \label{fig:isActive} 51 \label{fig:thread}
52 \end{center} 52 \end{center}
53 \end{figure} 53 \end{figure}
54 Jungleはreadを行う際にロックを必要としないため、複数のThreadから同時に読み込んでも速度が出ている。 54
55 今回は、分散環境下での測定が行えなかったため、最低限の測定しか行えていない。 55 Jungleは書き込みを行う際、読み込みに対するロックをかけないため、書き込みを行ってもほとんど読み込みに影響を及ぼさない。
56 次は、分散環境を整えて再計測を行う必要がる。 56 しかし、書き込みと読み込みを同時に行っているread\&writeの方は、書き込み分の負荷が多くかかっているため、やはりreadのみと比べると多少遅くなっている。
57 \section{Indexの作成時間}
58 57
59 58
59 図\ref{fig:thread}でもThreadCount5まではほとんど差は開いていない。
60 しかし、6Thread目以降はread\&writeの、8Thread目以降ではreadOnlyのreadCountの上昇量がゆるやかになり、差が開きだしている。
61 理由として、Jungleの処理限界が来たためであると推測でき、read\&writeがreadOnlyより早く処理限界が来た理由は、writeの分readOnlyよりリソースを多く使用しているためだと推測できる。
60 62
63 本実験で、Jungleは書き込み中でも高速に検索が行えることがわかった。
64 これはつまり、スケールアウトを行うためにデータのコピーを行う際、データベースをロックすること無く行えるということである。
65