Thread: Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方] (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz

下記、kai_tcp_server のコード片です。
---
acceptor_loop(Socket, State, Mod, Option) ->
    case gen_tcp:recv(
        Socket, Option:get(recv_length), Option:get(recv_timeout)
    ) of
        {ok, Data} ->
            case Mod:handle_call(Data, State) of
                {reply, DataToSend, State} ->
                    gen_tcp:send(Socket, DataToSend),
                    acceptor_loop(Socket, State, Mod, Option);
                {noreply, State} ->
                    acceptor_loop(Socket, State, Mod, Option);
                {setopts, SocketOptions, RecvLength, State} ->
                    inet:setopts(Socket, SocketOptions),
                    NewOption = kai_option:new(
                            [
                                {recv_length, RecvLength},
                                {recv_timeout, Option:get(recv_timeout)}
                            ],
                            ?DEFAULT_OPT_PROP
                    ),
                    acceptor_loop(Socket, State, Mod, NewOption);
                {close, DataToSend, State} ->
                    gen_tcp:send(Socket, DataToSend),
                    gen_tcp:close(Socket);
                _Error ->
                    gen_tcp:close(Socket)
            end;
        {error, Reason} ->
            exit({error, Reason})
    end.
---
たけまるさん版に改良を加え
Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。

※RecvLength あたりが美しくないですよね・・・
※まだ、kai_option を使っているのですが、これは後で別途相談を・・・

この状態で、kai_memcache を途中まで修正してみたのですが
put クエリ対応がカオスになってしまいました。
 ---
handle_call(Data, [{packet, line}] = State) ->
    dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).

dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
    {
        setopts,
        [{packet, raw}],
        Bytes,
        [{packet, raw}, {state, Key, Flags}]
    };
dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
    {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.

handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
    Data = #data{key=Key, flags=Flags, value=Value},
    case kai_coordinator:route({put, Data}) of
        ok ->
            {reply, <<"STORED\r\n">>, State};
        _Other ->
            send_error_and_close("Failed to read.", State)
    end.
---
作りかけなので、上記は、下記のようなバグを持っています。
・<<"STORED\r\n">> した後に {packet, line} に戻していない
・Value の後に続く、<<"\r\n">> を受信しきっていない

で、今後の対応として、下記の三つを考えております。
１．このまま続ける。
　　Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
　　このままいけそうな気がしています。カオスですが・・・。

２．Mod:handle_call に Socket を渡してしまう。
　　{packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
　　個人的には、これが一番良いかな？と思っています。

３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
　　http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
　　これに近い感じです。（そのままは使いません）

と言う事で、意見募集中です。

2008/6/25 Takeru INOUE <tak...@gm...>:
>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>
> はい，ガンガン進めちゃってください．
>
>> 念のため、branch を作ります。
>>
>> embed_tcp_server
>>
>> と言う branch で、如何でしょうか？
>
> それでもいいですし，kai/branches/cooldaemon/hoge/
> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>
>
>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>> おー、この方が素敵ですね！
>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>
>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>
>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>> supervisor 二重起動を許可しないといけませんね。
>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>
>>> そんな制約があるかもなのですね．
>>>
>>>> そう言えば、TrapExit かどこかで
>>>> application、supervisor、gen_server を
>>>> 一ファイルに記述する方法が掲載されていました。
>>>
>>> いろんな技があるのですねぇ．
>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>
>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>> module として持ち運びが簡単かなぁと思うのですが
>>>> コード量によっては、分割した方が良い気もします。
>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>
>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>
>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>> 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 っぽくて萌えるのですがｗ；）
>>>>>>>
>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>
>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>
>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>> お気になさらずにー。
>>>>>>>
>>>>>>> 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...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>


-- 
cooldaemon

Thread: Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方] (Page 2)

Kai is a distributed key-value datastore

kai-devel-ja