changeset 10:198cebfd31a3

modify chapter5
author sugi
date Sat, 10 Jan 2015 08:44:39 +0900
parents 7e1112025b3a
children 0b3e5436fa48
files paper/chapter4.tex paper/chapter5.tex paper/source/IncomingTcpConnection.java
diffstat 3 files changed, 87 insertions(+), 7 deletions(-) [+]
line wrap: on
line diff
--- a/paper/chapter4.tex	Thu Jan 08 20:36:01 2015 +0900
+++ b/paper/chapter4.tex	Sat Jan 10 08:44:39 2015 +0900
@@ -1,5 +1,6 @@
 \chapter{改善点} \label{chapter:chapter4}
 %この章では、分散フレームワークAliceに対して行った改善点を示す。
+
 \section{並列環境における改善}
 分散フレームワークAliceは、並列環境にも対応したフレームワークである。しかし、並列環境に対応していることを確認するためにbitonic sortを作成、計測したところ、Data Segmentの更新のオーバーヘッドにより、期待した効果を得ることができなかった。その際に、行った改善点を示す。
 \subsection{SEDA Architecture}
@@ -44,7 +45,7 @@
 この問題を解決するために、一般的なJavaのクラスオブジェクトでもデータ表現を可能にした。Local Data Segmentに対してputする場合は、Valueオブジェクトに変換せず一般的なJavaのクラスオブジェクトのままで、Remote Data Segmentに対してputする場合にのみValueに変換する。これにより、無駄な変換コストを抑えられるようになった。
 
 \section{分散環境における改善}
-AliceVNCを実装するにあたり、Aliceの送受信部分に問題が発見された。ここでは発見された問題の解決方法を示す。
+AliceVNCを実装するにあたり、Aliceの送受信部分に問題が発見された。ここでは発見された問題とその解決方法を示す。
 
 \subsection{Data Segmentのデータ表現の変更} \label {subsection:changeDSFormat}
 AliceVNCは、\ref {section:AliceVNC}で説明したように、当研究室で開発しているTreeVNCを分散フレームワークAliceを用いて実装した画面共有システムである。
@@ -53,6 +54,8 @@
 
 このValue型への変換が問題である。受け取ったデータを自分の子ノードに対して送信する際には、デシリアライズしValue型に変換する必要はない。シリアライズ状態のまま子ノードに送信すれば、Value型に変換するオーバーヘッドとValue型をシリアライズするオーバーヘッドを無くすことができる。そこで、Remoteからputされたデータ表現をValue型からbyteArrayで表現されたbinaryに変更した。また、Remoteにputする際にもValue型に変換せずに直接byteArrayに変換するように変換した。
 
+%オーバーヘッドの図を挿入予定
+
 しかし、この変更で新しい問題が発生した。Remoteからputされたデータは必ずbyteArrayで表現される。しかし、putされたbyteArrayが全てシリアライズ化された状態であるとはいえない。一般的なJavaのクラスオブジェクトとしてbyteArrayが使用されている場合が存在する。例えば、AliceVNCで使われる画像データはbyteArrayで表現されているが、これはLocalからputされている。 Input Data Segmentが格納されるReceiverクラスには{\tt asClass()}というメソッドがある。
 
 \begin{itemize}
@@ -77,6 +80,18 @@
 
 asClassが行う処理は、Localからputされたデータ({\tt serialized}と{\tt byteArray}がfalseの場合または{\tt byteArray}のみtrueの場合)は、目的のClassにcastする。Remoteからputされたデータ({\tt serialized}がtrueの場合)はMessage Packを使い変換する。
 
+\subsubsection{Message Packの機能追加}
+通信入力部はMessage PackのUnpackerを用いる事により、ストリームを次から次へとデシリアライズすることができる。
+しかし、提供されているAPIは全てデシリアライズを行うものであり、シリアライズ状態のオブジェクトを取得することができない。そこでUnpackerにシリアライズ状態のオブジェクトを取得するメソッドを追加した。
+
+\begin{table}[html]
+\lstinputlisting[label=src:Incoming, caption=ByteBuffer作成部分]{source/IncomingTcpConnection.java}
+\end{table}
+ソースコード\ref {src:Incoming} は受け取ったデータをLocal Data Segmentに追加する処理である。
+getSerializedByteArrayメソッドでシリアライズ状態のオブジェクトを取得している。
+
+このメソッドの実装をもって、受け取ったデータをデシリアライズせずに、子ノードに渡すことが可能となった。
+
 \subsection{パケットの再設計}
 Aliceの通信の際には、CommandMessage.classのインスタンスをMessage Packによりシリアライズ化したものが送信される。
 つまり、CommandMessage.classがパケットの構造を表すものといえる。
@@ -99,11 +114,11 @@
   \hline
   key&どのKeyに対して操作を行うか指定する\\
   \hline
-  val&Data Segment本体\\
+  val&データ本体\\
   \hline
   quickFlag&SEDAを挟まずCommandを処理を行うかを示す\\
   \hline
-  serialized&Data Segment本体のシリアライズ状態を示す\\
+  serialized&データ本体のシリアライズ状態を示す\\
   \hline
 \end{tabular}
 \end{center}
@@ -115,7 +130,7 @@
 \lstinputlisting[label=src:CommandMessage, caption=変更後のCommandMessage]{source/CommandMessage.java}
 \end{table}
 
-そこで、CommandMessageをソースコード\ref{src:CommandMessage}のように変更した。Data Segment本体をCommandMessageのフィールドから外し、後からByteBufferにまとめることにより2度のシリアライズを防ぐ。(ソースコード\ref{src:convert})
+そこで、CommandMessageをソースコード\ref{src:CommandMessage}のように変更した。データ本体をCommandMessageのフィールドから外し、後からByteBufferにまとめることにより2度のシリアライズを防ぐ。(ソースコード\ref{src:convert})
 
 \begin{table}[html]
 \lstinputlisting[label=src:convert, caption=ByteBuffer作成部分]{source/CreateByteBuffer.java}
--- a/paper/chapter5.tex	Thu Jan 08 20:36:01 2015 +0900
+++ b/paper/chapter5.tex	Sat Jan 10 08:44:39 2015 +0900
@@ -1,5 +1,57 @@
 \chapter{分散フレームワーク Alice の評価} \label{chapter:chapter5}
-\section{ringの測定(過去のAliceとの比較)}
-\section{FederatedLindaとの比較(先行研究との比較)}
-\section{no-tcp-delay}
+この章では、Aliceを用いた実験方法等についてまとめ、\label{chapter:chapter4}で行った効果の測定、先行研究であるFedarated Lindaとの性能比較を行い、評価を行なう。また、TreeVNCとAliceVNCの比較をコードの観点からも評価を行なう。
+\section{TORQUE Resource Manager を用いた実験方法}
+Aliceの性能を実験する際に、学科にある共用のブレードサーバーを用いた。TORQUE Resource Manager (\url{http://www.adaptivecomputing.com/products/torque.php})というジョブスケジューラーによって、他の利用者とのリソースが競合しないように管理されている。
+\section{ringの測定}
+
+\subsection{実験概要}
+\subsection{実験環境}
+\begin{table}[htbp]
+\caption{共有ブレードサーバーの詳細}
+\label{tb:blade8}
+\begin{center}
+\begin{tabular} {|l|l|}
+  \hline1
+  {\bf マシン台数}&8台\\
+  \hline
+  {\bf CPU}&Intel(R) Xeon(R) X5650 @ 2.67GHz\\
+  \hline
+  {\bf 物理コア数}&12\\
+  \hline
+  {\bf 論理コア数}&24\\
+  \hline
+  {\bf CPU キャッシュ}&12MB\\
+  \hline
+  {\bf Memory}&132GB\\
+  \hline
+\end{tabular}
+\end{center}
+\end{table}
+
+\begin{table}[htbp]
+\caption{仮想クラスタの詳細}
+\label{tb:VMware}
+\begin{center}
+\begin{tabular} {|l|l|}
+  \hline
+  {\bf マシン台数}&45台\\
+  \hline
+  {\bf CPU}&Intel(R) Xeon(R) X5650 @ 2.67GHz\\
+  \hline
+  {\bf 物理コア数}&2\\
+  \hline
+  {\bf 仮想コア数}&4\\
+  \hline
+  {\bf CPU キャッシュ}&12MB\\
+  \hline
+  {\bf Memory}&8GB\\
+  \hline
+\end{tabular}
+\end{center}
+\end{table}
+
+\subsection{改善点の効果測定}
+\subsection{FederatedLindaとの比較}
+\subsection{no-tcp-delay有無の比較}
+
 \section{TreeVNCとのCodeの比較}
\ No newline at end of file
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paper/source/IncomingTcpConnection.java	Sat Jan 10 08:44:39 2015 +0900
@@ -0,0 +1,13 @@
+while (true) {
+    Command cmd = null;
+    ReceiveData rData = null;
+    CommandMessage msg = unpacker.read(CommandMessage.class);
+    CommandType type = CommandType.getCommandTypeFromId(msg.type);
+    switch (type) {
+    case UPDATE:
+    case PUT:
+        int dataSize = unpacker.readInt();
+        rData = new ReceiveData(unpacker.getSerializedByteArray(dataSize), msg.compressed, msg.serialized);
+        cmd = new Command(type, null, null, rData, 0, 0, null, null, reverseKey);
+        lmanager.getDataSegmentKey(msg.key).runCommand(cmd);
+        break;