[論文レビュー] Browser-based distributed evolutionary computation: performance and scaling behavior

J. J. Merelo, Antonio Mora-García+3 more|ArXiv.org|Jan 18, 2007

Peer-to-Peer Network Technologies参考文献 13被引用数 4

ひとこと要約

本稿では、Ruby on Rails と AJAX を使用して、ウェブブラウザを介したアドホックな分散型進化的計算を可能にする、ブラウザベースのフレームワーク DCoR（Distributed Computation on Rails）を提案する。性能は、サーバー側のボトル neck に起因し、特にシングルスレッドでのリクエスト処理により、クライアント数の増加に伴いやや緩やかに向上するが、デバッグの無効化やログの削減といった最適化により平均で約 20% の向上が得られ、サーバー側のボトル neck を解消するためのアーキテクチャ変更の必要性が浮き彫りになる。

ABSTRACT

The challenge of ad-hoc computing is to find the way of taking advantage of spare cycles in an efficient way that takes into account all capabilities of the devices and interconnections available to them. In this paper we explore distributed evolutionary computation based on the Ruby on Rails framework, which overlays a Model-View-Controller on evolutionary computation. It allows anybody with a web browser (that is, mostly everybody connected to the Internet) to participate in an evolutionary computation experiment. Using a straightforward farming model, we consider different factors, such as the size of the population used. We are mostly interested in how they impact on performance, but also the scaling behavior when a non-trivial number of computers is applied to the problem. Experiments show the impact of different packet sizes on performance, as well as a quite limited scaling behavior, due to the characteristics of the server. Several solutions for that problem are proposed.

研究の動機と目的

• 特別なソフトウェアのインストールを必要とせずに、ウェブブラウザを分散型進化的計算の参加者として使用する可能性を検討すること。
• ウェブフレームワークを用いたブラウザベースの進化的計算システムの性能とスケーリング特性を評価すること。
• 複数のクライントリクエストを処理する際のサーバー・アーキテクチャにおける性能ボトル neck を同定すること。
• サーバー側の制限を克服し、スケーラビリティを向上させるためのアーキテクチャ的改善を提案すること。

提案手法

• システムは、サーバー側のロジックとクライント側の JavaScript 実行を可能にする Model-View-Controller (MVC) アーキテクチャを Ruby on Rails を用いて実装する。
• AJAX と XmlHttpRequest を使用して、クライント（ブラウザ）とサーバー間の非同期通信を実現し、ブロッキングを回避する計算とリアルタイムの更新を可能にする。
• 進化的計算は、クライントが染色体を評価し、その結果をサーバーに送信するファーミングモデルにより分散処理される。
• サーバーは評価レート（1 秒あたりの評価数）などのパフォーマンスメトリクスをログに記録し、パフォーマンスとスケーリングの分析に使用する。
• 実験では、パケットサイズ、集団サイズ、ネットワーク環境（ローカル、Fast Ethernet、WiFi）を変化させ、クライントを順次参加させる。
• パフォーマンスは、複数回の実行におけるボックスプロット形式で測定され、デバッグ有効／無効の状態での開発モードとプロダクションモードを比較する。

実験結果

リサーチクエスチョン

• RQ1 特別なアプリケーションのインストールを必要とせずに、ウェブブラウザを分散型進化的計算の計算ノードとして効果的に使用できるか？
• RQ2 クライント数の増加に伴い、ブラウザベースの進化的計算システムのパフォーマンスはどのようにスケーリングするか？
• RQ3 複数のブラウザクライントを処理する際の現在のサーバー・アーキテクチャにおける主なパフォーマンスボトル neck は何か？
• RQ4 デバッグモードやログ設定といったサーバー側の設定が、全体のシステムパフォーマンスにどのように影響するか？
• RQ5 スケーラビリティを顕著に向上させ、サーバー側のボトル neck を低減するためのアーキテクチャ的変更は何か？

主な発見

• 最初の数台のクライントではスケーリング性能が顕著に向上するが、4 〜 5 台を超えるとサーバー側の制限により頭打ちになる。
• サーバーのシングルスレッドでのリクエスト/レスポンスループが、並列処理を制限し、性能ボトル neck を引き起こしている。これは、マルチスレッドでのリクエスト処理が可能であっても同様に発生する。
• デバッグの無効化とログファイル I/O の削減により、平均パフォーマンスが約 20% 向上し、ログ処理が主要な競合要因であることが示唆される。
• 順次ログ出力によるロックの発生が、スレッド競合を引き起こし、最良ケースのシナリオでは改善が見られるものの、平均パフォーマンスの低下をさらに悪化させる。
• 現在のアーキテクチャではスケーラビリティが制限されており、クラスタとリバースプロキシの使用、またはより多くの計算をクライントに移管するといったアーキテクチャ的変更が、意味のあるスケーリングを実現するためには不可欠である。
• 最良ケースのパフォーマンスはクライント数の増加に伴い改善を続けるが、平均パフォーマンスの向上は停止に近づき、システム制限に起因するリターン・オブ・インベスメントの逓減が顕著になる。