kai-devel-ja Mailing List for kai (Page 12)

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

井上 (たけまる) です．

すいません，少し勘違いしていました．

今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
よく考えれば，

  - プロセスの生死を管理すること
  - 同時接続数を制限すること

これらは別の話ですね．

僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
(暇やつがいなければリクエストを待たせておく) という振る舞いでした．
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...>

2008	Jan	Feb	Mar	Apr	May (14)	Jun (95)	Jul (94)	Aug (44)	Sep (5)	Oct (8)	Nov (14)	Dec (6)
2009	Jan	Feb (18)	Mar (19)	Apr	May (11)	Jun (8)	Jul (4)	Aug	Sep (3)	Oct	Nov	Dec
2011	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

kai-devel-ja Mailing List for kai (Page 12)

Kai is a distributed key-value datastore

kai-devel-ja — For Kai developers in Japanese