Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]
Kai is a distributed key-value datastore
Status: Beta
Brought to you by:
takemaru
From: Tsukasa H. <ml...@cu...> - 2008-06-30 11:19:52
|
こんにちは、濱野です。 すっかり出遅れてしまいましたが、 1) accept した直後にプロセスを生成してコネクションを受け持つモデルと 2) 予め複数のプロセスを生成しておいて全て accept 待ちにしておく という2種類のモデルについて、思うところを書かせて頂きます。 まず、apache の挙動ですが、prefork にしろ worker モデルにしろ 一つのlisten ソケットに対し複数プロセスが 同時に accept(2) を呼び出さな いように何らかの方法で直列化を行っていたと思います。 http://httpd.apache.org/docs/2.0/ja/mod/mpm_common.html#acceptmutex Erlang の場合、R11B-3 からは SMP な Erlang VM でも場合同時に accept(2) を呼び出さないように何らかの方法でロックを行い直列してくれるようになっ たということだと思っているのですが、未確認ですので後で詳しく追ってみた いと思います。 また、apache が 予め複数のプロセスを立ち上げている理由というのは、プロ セスの起動が重いからという理由だったと思います。 そこでプロセス生成コストは軽いと言われている Erlang の場合で考えると、 両者のモデルにそう大きなパフォーマンスの違いは無いのではないかと考えて います。 むしろ、プロセスの起動コストを考えずに、必要な時に必要なだけのプロセス を spawn するのが erlang らしいプログラムなのではないかと思ってたりしま すが、(2) の方がコードが簡潔という点でのアドバンテージはあるかもしれま せん。 結局、何が言いたかったのかというと (1)のモデルでもそれほど悪くないんじゃ ないかなということでした。 # 最大接続数の制限でしたら、cooldaemon さんも仰るように(1) の方法でも行え ますよね。 パフォーマンスが気になるんだったら、さっさとベンチマーク取ればいいじゃ んと思われるかもしれませんが、最近やっと OTP 作法を覚えようとしてたり、 ぜんぜん手が追いついていない状況です、ごめんなさいごめんなさい。 At Wed, 25 Jun 2008 01:59:49 +0900, Takeru INOUE wrote: > > > http://d.hatena.ne.jp/cooldaemon/20071024/1193193093 > > ここの Server Design のアスキーアートをベースに話をします。 > > > > tcp_server_sup は、tcp_acceptor と tcp_client_sup を起動し監視下に置きます。 > > その際、tcp_acceptor を、最大接続数分 起動します。 > > これを読んで合点がいきました. > > > http://d.hatena.ne.jp/cooldaemon/20080624 > > こんな感じで、どうでしょうか? > > 素晴らしいです. > > せっかくなので,完全に OTP にしてみました. > 使いやすくなってるかは微妙.. > > たけまる / 続・Erlang で Apache worker MPM っぽいこと > http://teahut.sakura.ne.jp/b/2008-06-25-1.html > > > Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が > > シンプルでコード量が少ないですねぇ > > そういう気がします. > 同時に accept できるというのは比較的新しい機能のようですね. > > > 2008/6/24 masahito ikuta <coo...@gm...>: > >>> 僕がイメージしていたのは,つねに一定数のプロセスを起動しておいて,暇なやつにリクエストを処理させる > >>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした. > >> > >> メール&ブログのエントリを拝見致しましたが > >> たけまるさんと私の考え方は > >> 一致しているかなーと思います。 > >> ※私が勘違いしているかも? > >> > >>> cooldaemon さんの方法だと,プロセスの死活監視はできるのですが,プロセス数が一定ではないので,同時接続数を制限することはできません. > >> > >> Mochiweb もそうなのですが > >> accept した時点で、現在のプロセス数をインクリメントし > >> 最大接続数に達した時点で、accept を止めます。 > >> > >> プロセスが終了する度、EXIT メッセージが親に通達されるので > >> プロセス数をデクリメントします。 > >> (accept ループを抜けていた場合は、再開) > >> > >> なんとなくですが > >> 私は、accept するプロセスをプーリングする方式の方が > >> 速度が出そうな気がしますけれど。 > >> > >>> cooldaemon さんの方法は,プロセスを増やしながら生死を管理するための高度な方法です. > >> > >> ついでに、kai_api, kai_memcache のコードの共通化も可能です。 > >> > >> で、両者の良いとこ取りを出来ないかと思い > >> > >>>> spawn のコストが高くなった時点で > >>>> acceptor をプーリングしておく方式に切り替える事も > >>>> 検討材料として残しつつ、作業を進めます。 > >>>> > >>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。 > >>>> (名前は、kai_tcp_client_sup とかが良いでしょうか?) > >> > >> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。 > >> > >> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093 > >> ここの Server Design のアスキーアートをベースに話をします。 > >> > >> tcp_server_sup は、tcp_acceptor と tcp_client_sup を起動し監視下に置きます。 > >> その際、tcp_acceptor を、最大接続数分 起動します。 > >> > >> 接続があると、tcp_acceptor は > >> tcp_client_sup に tcp_echo(kai_memcache) を起動しなさい!と > >> メッセージを送ります。 > >> > >> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが > >> accept ループを出たり入ったりする処理を > >> 書かなくて良い点だけになってしまいますが・・・。 > >> (単一プロセスのループ処理を、複数プロセスに置き換えているところが > >> Erlang っぽくて萌えるのですがw;) > >> > >> 死活監視と接続最大数は別の話だとは思いつつも > >> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると > >> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。 > >> > >>> これに懲りずにおつきあいくださいませ. > >> > >> いやー、こういう話がないと、開発してる気分になれない気が(w; > >> お気になさらずにー。 > >> > >> 2008/6/23 Takeru INOUE <tak...@gm...>: > >>> 井上 (たけまる) です. > >>> > >>> すいません,少し勘違いしていました. > >>> > >>> 今回やろうとしていたことは,同時接続数の制限です (という言い方をすれば誤解がなかったのか). > >>> よく考えれば, > >>> > >>> - プロセスの生死を管理すること > >>> - 同時接続数を制限すること > >>> > >>> これらは別の話ですね. > >>> > >>> 僕がイメージしていたのは,つねに一定数のプロセスを起動しておいて,暇なやつにリクエストを処理させる > >>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした. > >>> cooldaemon さんの方法だと,プロセスの死活監視はできるのですが,プロセス数が一定ではないので,同時接続数を制限することはできません. > >>> > >>> cooldaemon さんの方法は,プロセスを増やしながら生死を管理するための高度な方法です. > >>> 今回の局面で使うには少し違うかも,という気がしています. > >>> 僕のイメージとは少し違ったのですが,有用な方法であることは間違いないので,どこかで役に立つと思います > >>> (まだ勘違いしてるかもしれないので,気づいた点がありましたら指摘してください><). > >>> > >>> 詳しくはブログに書きました. > >>> > >>> たけまる / Erlang で Apache worker MPM っぽいこと > >>> http://teahut.sakura.ne.jp/b/2008-06-23-1.html > >>> > >>> というわけで,混乱させてしまってすみません m(_ _)m > >>> これに懲りずにおつきあいくださいませ. > >>> > >>> > >>> 2008/6/23 masahito ikuta <coo...@gm...>: > >>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので,cooldaemon さんの方法のがよさそうです. > >>>> > >>>> spawn のコストが高くなった時点で > >>>> acceptor をプーリングしておく方式に切り替える事も > >>>> 検討材料として残しつつ、作業を進めます。 > >>>> > >>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。 > >>>> (名前は、kai_tcp_client_sup とかが良いでしょうか?) > >>>> > >>>> 2008/6/23 Takeru INOUE <tak...@gm...>: > >>>>>>>>- kai_api, kai_memcache のプロセスプール > >>>>>>> > >>>>>>> こちらの作業内容を > >>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか? > >>>>>>> (何となく、参加できそうな気がしたので・・・) > >>>>>> > >>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093 > >>>>>> ↑この仕組みで汎用化してしまい > >>>>>> tcp_acceptor の箇所で接続数の制限を行うのは > >>>>>> 如何でしょうか? > >>>>> > >>>>> はい,そんな感じです. > >>>>> > >>>>> やろうとしていることは,『プログラミングErlang』14.1 の最後に書いてあることそのままです. > >>>>> > >>>>> | Erlang バージョン R11B-3 では,1つの待ち受け用ソケットに > >>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが > >>>>> | できる.この機能を利用すれば,前もって生成しておいたプロセスのプー > >>>>> | ルを用意しておいて,その各プロセスを gen_tcp:accept/1 で接続待ち > >>>>> | 状態にしておくことができるので,並列サーバを作るのが簡単になる.(p.207) > >>>>> > >>>>> 僕がどうするつもりだったかというと,わりと適当にしか考えてなくて,『プログラミングErlang』付録D に出てくる lib_chan_cs > >>>>> のように,accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました. > >>>>> > >>>>> possibly_start_another(false, Listen, Active, Fun, max) -> > >>>>> case length(Active) of > >>>>> N when N < Max -> % worker 数が Max 未満なら > >>>>> New = start_accept(Listen, Fun), % accept 待ちプロセスを起動 > >>>>> > >>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので,cooldaemon さんの方法のがよさそうです. > >>>>> というわけで,いけそうなら sourceforge の tracker で自分にアサインしちゃってください. > >>>>> kai_api と kai_memcache がありますが,kai_memcache のほうがデバッグしやすい気がします. > >>>>> > >>>>> ちなみに,プロセスプールを TODO に入れた理由は次のとおりです. > >>>>> いまの Kai は,毎秒数百リクエストを送りつけると負荷が高くなって,メンバシップの管理ができなくなり,クラスタが分解してしまいます. > >>>>> これを回避できるとしたら,API の受け付け数を制限するしかないかなと. > >>>>> 『プログラミングErlang』でも,この機能をトラフィックシェーピング (流量制御) と読んでますね. > >>>>> > >>>>> > >>>>>> 2008/6/23 masahito ikuta <coo...@gm...>: > >>>>>>> cooldaemon です。 > >>>>>>> > >>>>>>>>- kai_api, kai_memcache のプロセスプール > >>>>>>> > >>>>>>> こちらの作業内容を > >>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか? > >>>>>>> (何となく、参加できそうな気がしたので・・・) > >>>>>>> > >>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います. > >>>>>>> > >>>>>>> とても細かい話で申し訳ないのですが・・・ > >>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので > >>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか? > >>>>>>> (autotools に対応する気力は無いのですが orz) > >>>>>>> > >>>>>>> > >>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>: > >>>>>>>> 井上 (たけまる) です. > >>>>>>>> > >>>>>>>> 6/19 にこのメールを送ったのですが,sourceforge の作業中だったから送られてないようなので (archive に表示されない),再送します. > >>>>>>>> > >>>>>>>> > >>>>>>>> ---------- Forwarded message ---------- > >>>>>>>> From: Takeru INOUE <tak...@gm...> > >>>>>>>> Date: 2008/6/19 > >>>>>>>> Subject: 開発の進め方 > >>>>>>>> To: kai...@li... > >>>>>>>> > >>>>>>>> > >>>>>>>> 井上 (たけまる) です. > >>>>>>>> > >>>>>>>> きのうは勉強会に参加いただきありがとうございました. > >>>>>>>> お陰様で,面白い会になったと思います. > >>>>>>>> > >>>>>>>> さて,開発の進め方についてです. > >>>>>>>> > >>>>>>>> まず,発表で言ったように,kai_memcache から coordinator の機能を分離しておきます. > >>>>>>>> また,kai_version という空のモジュールを作っておきます. > >>>>>>>> これで,基本的なモジュール構成が固まるので,開発しやすくなると思います. > >>>>>>>> > >>>>>>>> 次に,実装の順序についてです. > >>>>>>>> > >>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが,次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど). > >>>>>>>> > >>>>>>>> - ./configure > >>>>>>>> - test_server > >>>>>>>> - kai_store の永続化 > >>>>>>>> - kai_api, kai_memcache のプロセスプール > >>>>>>>> > >>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います. > >>>>>>>> > >>>>>>>> コミッタは 5-10名と多くないので,管理はゆるめで進めたいです. > >>>>>>>> 早い者勝ちで手を挙げた人が実装してみて,行き詰まったら ML などでヘルプを求めるというのでいいかなぁ. > >>>>>>>> 誰が取り組んでいるかを知るために,sourceforge の Tracker を使うべきかなぁ. > >>>>>>>> 適当にブランチを切って自由に進めてもらって,落ち着いたところで merge するというので大丈夫だろうか. > >>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも). > >>>>>>>> > >>>>>>>> といったあたりについて意見を聞かせてください. > >>>>>>>> > >>>>>>>> # こういった開発者のための意識合わせ的なことは,Wiki にまとめて後で周知します. > >>>>>>>> > >>>>>>>> # うまく回り始めたら,僕は全体のコーディネートにまわるつもりです. > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Takeru INOUE <tak...@gm...> > >>>>>>>> > >>>>>>>> ------------------------------------------------------------------------- > >>>>>>>> Check out the new SourceForge.net Marketplace. > >>>>>>>> It's the best place to buy or sell services for > >>>>>>>> just about anything Open Source. > >>>>>>>> http://sourceforge.net/services/buy/index.php > >>>>>>>> _______________________________________________ > >>>>>>>> Kai-devel-ja mailing list > >>>>>>>> Kai...@li... > >>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> cooldaemon > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> cooldaemon > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Takeru INOUE <tak...@gm...> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> cooldaemon > >>>> > >>> > >>> > >>> > >>> -- > >>> Takeru INOUE <tak...@gm...> > >>> > >> > >> > >> > >> -- > >> cooldaemon > >> > >> ------------------------------------------------------------------------- > >> Check out the new SourceForge.net Marketplace. > >> It's the best place to buy or sell services for > >> just about anything Open Source. > >> http://sourceforge.net/services/buy/index.php > >> _______________________________________________ > >> Kai-devel-ja mailing list > >> Kai...@li... > >> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja > >> > > > > > > > > -- > > cooldaemon > > > > > > -- > Takeru INOUE <tak...@gm...> > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Kai-devel-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-devel-ja -- Tsukasa Hamano <ha...@cu...> |