- 分散プログラムには信頼性とスケーラビリティが必要である
- しかし、両方を兼ね備えたプログラムを作成することは容易ではない
- そこで、当研究室では信頼性とスケーラビリティの両方をもったプログラムの記述をサポートする、分散フレームワークAliceを開発を行なっている
Data Segmentは数値や文字列を構造体的に保持する
Aliceではデータベース的に扱うが、通常とは異なりKey毎にQueueを持つ
以下のAPIでデータの送受信を行う
|
Aliceの並列性能は問題がある
作成した例題により以下のoverheadが見つかっている
マルチコアを活かすためにAliceではSEDA Architectureを採用している。
SEDAとはマルチコアスレッドを用いて大量の接続を管理し、
データを処理毎に分けられたステージと呼ばれるスレッドで処理を行う。
while(ture){
Command cmd = linkedBlockingQueue.take()
Command result = runCommand(cmd);
nextLinkedBlockingQueue.put(result);
}
今回SEDAは上記のソースコードのように実装されている
LinkedBlockingQueueにCommandが次々と投げられる
各ステージでQueueからCommandが取得され、Commandが実行され、
その結果が次のステージのQueueに投げられる
もし、Queueが空の場合にはブロッキングされenqueueされるまで待つ
SEDA Architectureを実装するにあたり、LinkedBlockingQueueを使用している。
特徴としてSEDAは多段のパイプラインによって構成されるためレスポンスが遅れる。
スループット重視の実装であるため、レスポンスが要求される
Sortのようなプログラムに向いていない。
非力なマシーンでは、スレッドを切り替えが頻繁に起こり、
レスポンスを下げる要因になる。
並列タスク管理フレームワークCeriumでもコピーによるoverheadがあり、Input Data SegmentとOutput Data Segmentをswapすることで解決している。
Aliceでも同様の方法で解決する。
今回行った改善による効果を調べるために3つの実験を行った。
実験はSEDAの効果が出るようにメニコアのマシンで行った
Data Segmentを取得するCode Segmentが10000回実行されるまでの時間を測定
既存のAPIのputと新しく追加したAPIであるflipを使用して10000回、Data Segmentを追加されるまでの時間を測定
今回行った改善でBitonic Sortがどの程度速度が改善されたか測定する。
要素は100万個、10個に分割して実験した
実験結果は100回行った平均
| SEDA | あり | なし |
|---|---|---|
| 実行時間(ms) | 27.72 | 7.53 |
| API | flip | put |
|---|---|---|
| 実行時間(ms) | 61.12 | 65.24 |
| 改善前 | 改善後 | |
|---|---|---|
| 実行時間(ms) | 199.38 | 184.64 |