Blocking I/OとNon Blocking I/Oについて

2009年4月24日 at 1:03 AM



以前、Grizzlyの概要 : C10K問題に対応するGlassFish(Grizzly) というエントリで、

Grizzly が実装している Non Blocking I/O の利点について説明しましたが、

Project Kenai 中のプロジェクト Grizzly-send file 内で過去に書いたエントリの

補足となるような良い説明資料があがっていましたので、こちらでも紹介します。



※ このエントリを読む前に是非、過去の記事をご覧ください。



マルチスレッドで実装された Webサーバ は下記のようにAcceptor スレッドとWorker スレッドの間に

Queueを置いて、処理の効率化をはかっています。






この時、仮に Worker スレッドの数が5個だった場合に8クライアントから同時にファイル取得の

要求が来た場合を想定します。







Blocking I/Oを使って実装されたマルチスレッドサーバの場合、実際に作業ができるWorker スレッドは

5つしかありませんので、3つのクライアントは他の処理が終わるまで Queue で待たなければなりません。

取得する対象のコンテンツサイズが小さい、もしくはすぐに完了するような場合、このBlocking I/O

のマルチスレッドサーバは高速に動作します。



しかし、クライアントからのリクエスト数が膨大になった場合や、取得するコンテンツのサイズが大きい場合、

もしくはコンテンツの取得に時間がかかるような場合、他のクライアントの要求に対して影響が大きいことが

わかります。









一方、Grizzly のように Non Blocking I/O に対応した Web Server を利用すると、Woker スレッドを

効率的に利用することができるようになります。








5つの Woker スレッドが8クライアントからの同時アクセスに対して、各スレッド毎で分割して

処理できますので、誰か1人が大きなファイルを取得したとしても他の人に対して影響は少なく

なります。

そこで、クライアントからのリクエスト数が増えれば増える程、Non Blocking I/Oの実装の恩恵を

受ける事ができます。



PS.

今回は Project Kenai の Grizzly-Send file の画像を使わさせて頂きました。

私が作成した概念図より各スレッド毎に分割されて処理しているのが

分かりやすいので、二つの資料を両方つかうとわかりやすいですね。


広告

Entry filed under: Application Server/GlassFish. Tags: , .

プロジェクト Kenai について Atmosphere 0.1 GA リリース


Java Champion & Evangelist

ご注意

このエントリは個人の見解であり、所属する会社の公式見解ではありません

カレンダー

2009年4月
« 3月   5月 »
 12345
6789101112
13141516171819
20212223242526
27282930  

カテゴリー

Twitter

clustermap

ブログ統計情報

  • 986,641 hits

Feeds


%d人のブロガーが「いいね」をつけました。