|
0
|
1 \chapter{改善点} \label{chapter:chapter4}
|
|
7
|
2 %この章では、分散フレームワークAliceに対して行った改善点を示す。
|
|
|
3 \section{並列環境における改善}
|
|
8
|
4 分散フレームワークAliceは、並列環境にも対応したフレームワークである。しかし、並列環境に対応していることを確認するためにbitonic sortを作成、計測したところ、Data Segmentの更新のオーバーヘッドにより、期待した効果を得ることができなかった。その際に、行った改善点を示す。
|
|
7
|
5 \subsection{SEDA Architecture}
|
|
|
6 SEDA Architectureとはマルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させていく処理方式である。
|
|
|
7 スループット重視のでありレスポンスは多段のパイプラインのせいで遅れてしまう。
|
|
|
8 Aliceに置いてSEDAを実装するにあたり、データを次のステージにへ伝搬する際、LinkedBlockingQueueを使用している。LinkedBlockingQueueは片方向の連結リストをベースとしたQueue実装である。enqueue / dequeueの操作時の排他制御にはそれぞれ別々のロックオブジェクトが使用されている。そのため、enqueueとdequeueが重なってもロック解除待ちは発生しないが、そのかわりに連結リストのNodeオブジェクトの生成操作などが発生してしまうため、enqueue操作の処理コストが高い。
|
|
|
9 さらに、非力なマシーンではSEDAの効果を得られず、スレッドを切り替えが頻繁に起こりオーバーヘッドになってしまう。
|
|
|
10
|
|
|
11 以上の理由からLocal Data Segmentに対して操作をする際はSEDAを使用せず処理を行なうように変更した。
|
|
|
12 変更前は、Local Data Segmentに対して操作する場合、putやpeekに沿ったCommandを作成するステージ(Code Segmentが実行されているスレッド)、受け取ったCommandを処理するステージ、Code SegmentにData Segmentをセットするステージ（peekとtakeの場合）の2段または3段のパイプラインで構成されていた。これらを1つのステージにまとめて処理することで、並列環境における性能を向上させた。
|
|
8
|
13
|
|
7
|
14 \subsection{Data Segment の再構成（flip 機能の追加）}
|
|
8
|
15 Data Segment APIのput、updateを呼ぶとOutput Data Segmentが毎回新しく作成される。そして出力するデータのコピーが行われる。しかし、Input Data Segmentとして取得したデータに変更を行い、Output Data Segmentとして出力する場合、コピーを行なうのは無駄である。そこで、このコピーを減らすことで速度改善を行った。
|
|
|
16
|
|
|
17 このコピーを無くし、Data Segmentの更新におけるオーバーヘッドを減らす方法としてCeriumでも良好な結果を得ているflipを用いた。Ceriumにおけるflipは、Input Data SegmentとOutput Data SegmentをswapさせるAPIである。(ソースコード \ref{src:flipCerium})
|
|
|
18
|
|
|
19 \begin{table}[html]
|
|
|
20 \lstinputlisting[label=src:flipCerium, caption=Ceriumにおけるflip]{source/flip.cc}
|
|
|
21 \end{table}
|
|
|
22
|
|
|
23
|
|
|
24 \begin{table}[html]
|
|
|
25 \lstinputlisting[label=src:flipAlice, caption=Aliceにおけるflip]{source/flip.java}
|
|
|
26 \end{table}
|
|
|
27
|
|
|
28 \begin{table}[html]
|
|
|
29 \lstinputlisting[label=src:exampleFlip,caption=flipの使用例]{source/Sort.java}
|
|
|
30 \end{table}
|
|
|
31
|
|
|
32 Ceriumの場合、Output Data SegmentはTaskが実行された段階ですでに用意されている。そのためデータをOutput Data Segmentに書き込む前にflipを呼ぶ。
|
|
|
33 Aliceの場合、putまたはupdateを呼んだ段階でOutput Data Segmentが作られるため、ソースコード\ref{src:exampleFlip}のようにInput Data SegmentであるReceiverをflipメソッドに引数として渡すことで、無駄なコピーを減らす。
|
|
|
34
|
|
7
|
35 \subsection{Data Segmentのデータ表現の追加}
|
|
|
36 変更前はData Segmentのデータ表現はMessage Pack for JaveのValueオブジェクトのみを用いて表現していた。
|
|
|
37 Valueオブジェクトとは、Message Packのバイナリにシリアライズできる型のみで構成されたJavaのオブジェクトであり、自己記述形式のデータ形式となっている。そのため、ArrayValueを用いることにより、ユーザーはデータを後からつなげたりすることも可能である。
|
|
|
38
|
|
|
39 このValueオブジェクトの特徴の1つに、通信に関わる際のシリアライズ・デシリアライズを高速に行えることがある。
|
|
|
40 この特徴を用いて、Remote Data Segmentに対する通信の高速化を狙っていた。
|
|
|
41
|
|
|
42 しかし、Local Data Segmentに対する通信においては逆効果である。データをLocal Data Segmentに対してputするたびにValue型に変換するコストがかかる。データをpeekする際にもValue型から元の型に変換するというコストがかかる。
|
|
|
43
|
|
|
44 この問題を解決するために、一般的なJavaのクラスオブジェクトでもデータ表現を可能にした。Local Data Segmentに対してputする場合は、Valueオブジェクトに変換せず一般的なJavaのクラスオブジェクトのままで、Remote Data Segmentに対してputする場合にのみValueに変換する。これにより、無駄な変換コストを抑えられるようになった。
|
|
9
|
45
|
|
7
|
46 \section{分散環境における改善}
|
|
8
|
47 AliceVNCを実装するにあたり、Aliceの送受信部分に問題が発見された。ここでは発見された問題の解決方法を示す。
|
|
9
|
48
|
|
|
49 \subsection{Data Segmentのデータ表現の変更} \label {subsection:changeDSFormat}
|
|
8
|
50 AliceVNCは、\ref {section:AliceVNC}で説明したように、当研究室で開発しているTreeVNCを分散フレームワークAliceを用いて実装した画面共有システムである。
|
|
|
51
|
|
|
52 Topology Nodeは受け取った画面データを描画すると同時に、Remote Data Segmentに送信する。Remote Data Segmentに送信する際にはMessage PackによりValue型に変換し、その後シリアライズ化（byteArrayで表現されたバイナリに変換）される。Topology Nodeは受信するとデシリアライズしValue型に変換した後putされる。
|
|
|
53
|
|
9
|
54 このValue型への変換が問題である。受け取ったデータを自分の子ノードに対して送信する際には、デシリアライズしValue型に変換する必要はない。シリアライズ状態のまま子ノードに送信すれば、Value型に変換するオーバーヘッドとValue型をシリアライズするオーバーヘッドを無くすことができる。そこで、Remoteからputされたデータ表現をValue型からbyteArrayで表現されたbinaryに変更した。また、Remoteにputする際にもValue型に変換せずに直接byteArrayに変換するように変換した。
|
|
|
55
|
|
|
56 しかし、この変更で新しい問題が発生した。Remoteからputされたデータは必ずbyteArrayで表現される。しかし、putされたbyteArrayが全てシリアライズ化された状態であるとはいえない。一般的なJavaのクラスオブジェクトとしてbyteArrayが使用されている場合が存在する。例えば、AliceVNCで使われる画像データはbyteArrayで表現されているが、これはLocalからputされている。 Input Data Segmentが格納されるReceiverクラスには{\tt asClass()}というメソッドがある。
|
|
|
57
|
|
|
58 \begin{itemize}
|
|
|
59 \item \verb+public <T> T asClass(Class<T> clazz)+
|
|
|
60 \end{itemize}
|
|
|
61
|
|
|
62 このメソッドは取得したデータがRemoteからputされた場合、Value型でなっているためMessage Packを使い適切な型に変換するものである。しかし、byteArray型に変更したため、変換可否を判断することができなくなってしまった。
|
|
|
63
|
|
|
64 ここからわかることは、データを表現するにはデータ単体をやりとりするだけでは不十分ということである。変更以前はValue型であるということが状態を表していた。しかし、一般的なJavaのクラスオブジェクトとbyteArrayで表現されたbinaryが混在する現在では、データと一緒にデータの状態を表すメタデータもやりとりする必要がある。そこで、データとデータの状態を1つのオブジェクトにまとめ扱うように変更した。(ソースコード\ref {src:ReceiveData})
|
|
|
65
|
|
|
66 \begin{table}[html]
|
|
|
67 \lstinputlisting[label=src:ReceiveData, caption=データを表現するクラス]{source/ReceiveData.java}
|
|
|
68 \end{table}
|
|
|
69
|
|
|
70 {\tt val}がデータ本体が保存格納される。{\tt serialized}と{\tt byteArray}がデータの状態を表すメタデータである。{\tt serialized}
|
|
|
71 は、データ本体がシリアライズ化されているかを示す。{\tt byteArray}がデータ本体がbyteArrayであるかを示す。
|
|
|
72 この2つの状態があることで{\tt asClass()}を使い、適切に変換することができる。(ソースコード\ref {src:asClass})
|
|
|
73
|
|
|
74 \begin{table}[html]
|
|
|
75 \lstinputlisting[label=src:asClass, caption=asClassの処理]{source/asClass.java}
|
|
|
76 \end{table}
|
|
|
77
|
|
|
78 asClassが行う処理は、Localからputされたデータ（{\tt serialized}と{\tt byteArray}がfalseの場合または{\tt byteArray}のみtrueの場合）は、目的のClassにcastする。Remoteからputされたデータ（{\tt serialized}がtrueの場合）はMessage Packを使い変換する。
|
|
|
79
|
|
|
80 \subsection{パケットの再設計}
|
|
|
81 Aliceの通信の際には、CommandMessage.classのインスタンスをMessage Packによりシリアライズ化したものが送信される。
|
|
|
82 つまり、CommandMessage.classがパケットの構造を表すものといえる。
|
|
|
83
|
|
|
84 \begin{table}[html]
|
|
|
85 \lstinputlisting[label=src:CommandMessageBefore, caption=変更前のCommandMessage]{source/CommandMessagebefore.java}
|
|
|
86 \end{table}
|
|
|
87 ソースコード\ref {src:CommandMessageBefore}が変更前のCommandMessageの内容である。表\ref{tb:variable}はCommandMessageの各変数が何を表しているかを示したものである。
|
|
|
88 \begin{table}[htbp]
|
|
|
89 \caption{CommandMessageの変数名の説明}
|
|
|
90 \label{tb:variable}
|
|
|
91 \begin{center}
|
|
|
92 \begin{tabular} {|l|l|}
|
|
|
93 \hline
|
|
|
94 変数名&説明\\
|
|
|
95 \hline
|
|
|
96 type&CommandType {\tt PEEK, PUT}などを表す\\
|
|
|
97 \hline
|
|
|
98 seq&Data Segmentの待ち合わせを行っているCode Segmentを表すunique number\\
|
|
|
99 \hline
|
|
|
100 key&どのKeyに対して操作を行うか指定する\\
|
|
|
101 \hline
|
|
|
102 val&Data Segment本体\\
|
|
|
103 \hline
|
|
|
104 quickFlag&SEDAを挟まずCommandを処理を行うかを示す\\
|
|
|
105 \hline
|
|
|
106 serialized&Data Segment本体のシリアライズ状態を示す\\
|
|
|
107 \hline
|
|
|
108 \end{tabular}
|
|
|
109 \end{center}
|
|
|
110 \end{table}
|
|
|
111
|
|
|
112 このパケット構造に問題が存在する。データ本体はCommandMessageがシリアライズ化されるときにはすでに、シリアライズされている。つまり、このままCommandMessageをシリアライズ化を行うと、データ本体をもう1度シリアライズ化を行ってしまう。配列をシリアライズ化する場合、配列のサイズによってはオーバーヘッドが大きいため、2度シリアライズするのを防がなければならない。
|
|
|
113
|
|
|
114 \begin{table}[html]
|
|
|
115 \lstinputlisting[label=src:CommandMessage, caption=変更後のCommandMessage]{source/CommandMessage.java}
|
|
|
116 \end{table}
|
|
|
117
|
|
|
118 そこで、CommandMessageをソースコード\ref{src:CommandMessage}のように変更した。Data Segment本体をCommandMessageのフィールドから外し、後からByteBufferにまとめることにより2度のシリアライズを防ぐ。(ソースコード\ref{src:convert})
|
|
|
119
|
|
|
120 \begin{table}[html]
|
|
|
121 \lstinputlisting[label=src:convert, caption=ByteBuffer作成部分]{source/CreateByteBuffer.java}
|
|
|
122 \end{table}
|
|
|
123
|
|
|
124 この実装ではCommandMessage部をヘッダーとして扱っている。データ部はCommandTypeが{\tt UPDATE、PUT、REPLY}の時のみ後から付加される。以前の実装ではbyte[]の値としてnullを示すNilValueがあるものとしてシリアライズ化されており、これもオーバーヘッドである。現在の実装にでは、CommandTypeが{\tt UPDATE、PUT、REPLY}以外はの時は、データ部をシリアライズ化しないため、nullをシリアライズ化するオーバーヘッドはなくなっている。 |
