Mercurial > hg > Papers > 2015 > sugi-master
comparison paper/chapter4.tex @ 10:198cebfd31a3
modify chapter5
author | sugi |
---|---|
date | Sat, 10 Jan 2015 08:44:39 +0900 |
parents | 7e1112025b3a |
children | ddab34e04068 |
comparison
equal
deleted
inserted
replaced
9:7e1112025b3a | 10:198cebfd31a3 |
---|---|
1 \chapter{改善点} \label{chapter:chapter4} | 1 \chapter{改善点} \label{chapter:chapter4} |
2 %この章では、分散フレームワークAliceに対して行った改善点を示す。 | 2 %この章では、分散フレームワークAliceに対して行った改善点を示す。 |
3 | |
3 \section{並列環境における改善} | 4 \section{並列環境における改善} |
4 分散フレームワークAliceは、並列環境にも対応したフレームワークである。しかし、並列環境に対応していることを確認するためにbitonic sortを作成、計測したところ、Data Segmentの更新のオーバーヘッドにより、期待した効果を得ることができなかった。その際に、行った改善点を示す。 | 5 分散フレームワークAliceは、並列環境にも対応したフレームワークである。しかし、並列環境に対応していることを確認するためにbitonic sortを作成、計測したところ、Data Segmentの更新のオーバーヘッドにより、期待した効果を得ることができなかった。その際に、行った改善点を示す。 |
5 \subsection{SEDA Architecture} | 6 \subsection{SEDA Architecture} |
6 SEDA Architectureとはマルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させていく処理方式である。 | 7 SEDA Architectureとはマルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させていく処理方式である。 |
7 スループット重視のでありレスポンスは多段のパイプラインのせいで遅れてしまう。 | 8 スループット重視のでありレスポンスは多段のパイプラインのせいで遅れてしまう。 |
42 しかし、Local Data Segmentに対する通信においては逆効果である。データをLocal Data Segmentに対してputするたびにValue型に変換するコストがかかる。データをpeekする際にもValue型から元の型に変換するというコストがかかる。 | 43 しかし、Local Data Segmentに対する通信においては逆効果である。データをLocal Data Segmentに対してputするたびにValue型に変換するコストがかかる。データをpeekする際にもValue型から元の型に変換するというコストがかかる。 |
43 | 44 |
44 この問題を解決するために、一般的なJavaのクラスオブジェクトでもデータ表現を可能にした。Local Data Segmentに対してputする場合は、Valueオブジェクトに変換せず一般的なJavaのクラスオブジェクトのままで、Remote Data Segmentに対してputする場合にのみValueに変換する。これにより、無駄な変換コストを抑えられるようになった。 | 45 この問題を解決するために、一般的なJavaのクラスオブジェクトでもデータ表現を可能にした。Local Data Segmentに対してputする場合は、Valueオブジェクトに変換せず一般的なJavaのクラスオブジェクトのままで、Remote Data Segmentに対してputする場合にのみValueに変換する。これにより、無駄な変換コストを抑えられるようになった。 |
45 | 46 |
46 \section{分散環境における改善} | 47 \section{分散環境における改善} |
47 AliceVNCを実装するにあたり、Aliceの送受信部分に問題が発見された。ここでは発見された問題の解決方法を示す。 | 48 AliceVNCを実装するにあたり、Aliceの送受信部分に問題が発見された。ここでは発見された問題とその解決方法を示す。 |
48 | 49 |
49 \subsection{Data Segmentのデータ表現の変更} \label {subsection:changeDSFormat} | 50 \subsection{Data Segmentのデータ表現の変更} \label {subsection:changeDSFormat} |
50 AliceVNCは、\ref {section:AliceVNC}で説明したように、当研究室で開発しているTreeVNCを分散フレームワークAliceを用いて実装した画面共有システムである。 | 51 AliceVNCは、\ref {section:AliceVNC}で説明したように、当研究室で開発しているTreeVNCを分散フレームワークAliceを用いて実装した画面共有システムである。 |
51 | 52 |
52 Topology Nodeは受け取った画面データを描画すると同時に、Remote Data Segmentに送信する。Remote Data Segmentに送信する際にはMessage PackによりValue型に変換し、その後シリアライズ化(byteArrayで表現されたバイナリに変換)される。Topology Nodeは受信するとデシリアライズしValue型に変換した後putされる。 | 53 Topology Nodeは受け取った画面データを描画すると同時に、Remote Data Segmentに送信する。Remote Data Segmentに送信する際にはMessage PackによりValue型に変換し、その後シリアライズ化(byteArrayで表現されたバイナリに変換)される。Topology Nodeは受信するとデシリアライズしValue型に変換した後putされる。 |
53 | 54 |
54 このValue型への変換が問題である。受け取ったデータを自分の子ノードに対して送信する際には、デシリアライズしValue型に変換する必要はない。シリアライズ状態のまま子ノードに送信すれば、Value型に変換するオーバーヘッドとValue型をシリアライズするオーバーヘッドを無くすことができる。そこで、Remoteからputされたデータ表現をValue型からbyteArrayで表現されたbinaryに変更した。また、Remoteにputする際にもValue型に変換せずに直接byteArrayに変換するように変換した。 | 55 このValue型への変換が問題である。受け取ったデータを自分の子ノードに対して送信する際には、デシリアライズしValue型に変換する必要はない。シリアライズ状態のまま子ノードに送信すれば、Value型に変換するオーバーヘッドとValue型をシリアライズするオーバーヘッドを無くすことができる。そこで、Remoteからputされたデータ表現をValue型からbyteArrayで表現されたbinaryに変更した。また、Remoteにputする際にもValue型に変換せずに直接byteArrayに変換するように変換した。 |
56 | |
57 %オーバーヘッドの図を挿入予定 | |
55 | 58 |
56 しかし、この変更で新しい問題が発生した。Remoteからputされたデータは必ずbyteArrayで表現される。しかし、putされたbyteArrayが全てシリアライズ化された状態であるとはいえない。一般的なJavaのクラスオブジェクトとしてbyteArrayが使用されている場合が存在する。例えば、AliceVNCで使われる画像データはbyteArrayで表現されているが、これはLocalからputされている。 Input Data Segmentが格納されるReceiverクラスには{\tt asClass()}というメソッドがある。 | 59 しかし、この変更で新しい問題が発生した。Remoteからputされたデータは必ずbyteArrayで表現される。しかし、putされたbyteArrayが全てシリアライズ化された状態であるとはいえない。一般的なJavaのクラスオブジェクトとしてbyteArrayが使用されている場合が存在する。例えば、AliceVNCで使われる画像データはbyteArrayで表現されているが、これはLocalからputされている。 Input Data Segmentが格納されるReceiverクラスには{\tt asClass()}というメソッドがある。 |
57 | 60 |
58 \begin{itemize} | 61 \begin{itemize} |
59 \item \verb+public <T> T asClass(Class<T> clazz)+ | 62 \item \verb+public <T> T asClass(Class<T> clazz)+ |
75 \lstinputlisting[label=src:asClass, caption=asClassの処理]{source/asClass.java} | 78 \lstinputlisting[label=src:asClass, caption=asClassの処理]{source/asClass.java} |
76 \end{table} | 79 \end{table} |
77 | 80 |
78 asClassが行う処理は、Localからputされたデータ({\tt serialized}と{\tt byteArray}がfalseの場合または{\tt byteArray}のみtrueの場合)は、目的のClassにcastする。Remoteからputされたデータ({\tt serialized}がtrueの場合)はMessage Packを使い変換する。 | 81 asClassが行う処理は、Localからputされたデータ({\tt serialized}と{\tt byteArray}がfalseの場合または{\tt byteArray}のみtrueの場合)は、目的のClassにcastする。Remoteからputされたデータ({\tt serialized}がtrueの場合)はMessage Packを使い変換する。 |
79 | 82 |
83 \subsubsection{Message Packの機能追加} | |
84 通信入力部はMessage PackのUnpackerを用いる事により、ストリームを次から次へとデシリアライズすることができる。 | |
85 しかし、提供されているAPIは全てデシリアライズを行うものであり、シリアライズ状態のオブジェクトを取得することができない。そこでUnpackerにシリアライズ状態のオブジェクトを取得するメソッドを追加した。 | |
86 | |
87 \begin{table}[html] | |
88 \lstinputlisting[label=src:Incoming, caption=ByteBuffer作成部分]{source/IncomingTcpConnection.java} | |
89 \end{table} | |
90 ソースコード\ref {src:Incoming} は受け取ったデータをLocal Data Segmentに追加する処理である。 | |
91 getSerializedByteArrayメソッドでシリアライズ状態のオブジェクトを取得している。 | |
92 | |
93 このメソッドの実装をもって、受け取ったデータをデシリアライズせずに、子ノードに渡すことが可能となった。 | |
94 | |
80 \subsection{パケットの再設計} | 95 \subsection{パケットの再設計} |
81 Aliceの通信の際には、CommandMessage.classのインスタンスをMessage Packによりシリアライズ化したものが送信される。 | 96 Aliceの通信の際には、CommandMessage.classのインスタンスをMessage Packによりシリアライズ化したものが送信される。 |
82 つまり、CommandMessage.classがパケットの構造を表すものといえる。 | 97 つまり、CommandMessage.classがパケットの構造を表すものといえる。 |
83 | 98 |
84 \begin{table}[html] | 99 \begin{table}[html] |
97 \hline | 112 \hline |
98 seq&Data Segmentの待ち合わせを行っているCode Segmentを表すunique number\\ | 113 seq&Data Segmentの待ち合わせを行っているCode Segmentを表すunique number\\ |
99 \hline | 114 \hline |
100 key&どのKeyに対して操作を行うか指定する\\ | 115 key&どのKeyに対して操作を行うか指定する\\ |
101 \hline | 116 \hline |
102 val&Data Segment本体\\ | 117 val&データ本体\\ |
103 \hline | 118 \hline |
104 quickFlag&SEDAを挟まずCommandを処理を行うかを示す\\ | 119 quickFlag&SEDAを挟まずCommandを処理を行うかを示す\\ |
105 \hline | 120 \hline |
106 serialized&Data Segment本体のシリアライズ状態を示す\\ | 121 serialized&データ本体のシリアライズ状態を示す\\ |
107 \hline | 122 \hline |
108 \end{tabular} | 123 \end{tabular} |
109 \end{center} | 124 \end{center} |
110 \end{table} | 125 \end{table} |
111 | 126 |
113 | 128 |
114 \begin{table}[html] | 129 \begin{table}[html] |
115 \lstinputlisting[label=src:CommandMessage, caption=変更後のCommandMessage]{source/CommandMessage.java} | 130 \lstinputlisting[label=src:CommandMessage, caption=変更後のCommandMessage]{source/CommandMessage.java} |
116 \end{table} | 131 \end{table} |
117 | 132 |
118 そこで、CommandMessageをソースコード\ref{src:CommandMessage}のように変更した。Data Segment本体をCommandMessageのフィールドから外し、後からByteBufferにまとめることにより2度のシリアライズを防ぐ。(ソースコード\ref{src:convert}) | 133 そこで、CommandMessageをソースコード\ref{src:CommandMessage}のように変更した。データ本体をCommandMessageのフィールドから外し、後からByteBufferにまとめることにより2度のシリアライズを防ぐ。(ソースコード\ref{src:convert}) |
119 | 134 |
120 \begin{table}[html] | 135 \begin{table}[html] |
121 \lstinputlisting[label=src:convert, caption=ByteBuffer作成部分]{source/CreateByteBuffer.java} | 136 \lstinputlisting[label=src:convert, caption=ByteBuffer作成部分]{source/CreateByteBuffer.java} |
122 \end{table} | 137 \end{table} |
123 | 138 |