Thread: Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]
Kai is a distributed key-value datastore
Status: Beta
Brought to you by:
takemaru
Menu
▾
▴
kai-devel-ja
|
From: Takeru I. <tak...@gm...> - 2008-06-22 16:06:30
|
>>>- 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...> |
|
From: masahito i. <coo...@gm...> - 2008-06-23 01:28:22
|
> ただこの方法だと 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 |
|
From: Takeru I. <tak...@gm...> - 2008-06-23 13:45:25
|
井上 (たけまる) です． すいません，少し勘違いしていました． 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)． よく考えれば， - プロセスの生死を管理すること - 同時接続数を制限すること これらは別の話ですね． 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる (暇やつがいなければリクエストを待たせておく) という振る舞いでした． 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...> |
|
From: masahito i. <coo...@gm...> - 2008-06-24 00:03:13
|
> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる > (暇やつがいなければリクエストを待たせておく) という振る舞いでした． メール＆ブログのエントリを拝見致しましたが たけまるさんと私の考え方は 一致しているかなーと思います。 ※私が勘違いしているかも？ > 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 |
|
From: masahito i. <coo...@gm...> - 2008-06-24 13:49:29
|
http://d.hatena.ne.jp/cooldaemon/20080624 こんな感じで、どうでしょうか？ Mochiweb 方式より、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 |
|
From: Takeru I. <tak...@gm...> - 2008-06-24 17:00:15
|
> 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...> |
|
From: Takeru I. <tak...@gm...> - 2008-06-29 14:00:46
|
Voluntus さんの Twitter に，先日話題になった tcp_server 的なのを発見しました． Erlang: A Generalized TCP Server | 20bits http://20bits.com/2008/06/16/erlang-a-generalized-tcp-server/ といっても，プロセスプールは作られないですし，callback の単位がメッセージではなく accept なので，これに移行する必要はないですが，参考まで． 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...> > -- Takeru INOUE <tak...@gm...> |
|
From: masahito i. <coo...@gm...> - 2008-06-24 23:49:55
|
おー、この方が素敵ですね！ tcp_server.erl 用に behaviour を作っても良いかもしれませんね。 あと、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 |
|
From: Takeru I. <tak...@gm...> - 2008-06-25 00:54:07
|
> おー、この方が素敵ですね！ > 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...> |
|
From: masahito i. <coo...@gm...> - 2008-06-25 05:28:17
|
では、諸々考慮しつつ、kai へ組み込んでみますね。 念のため、branch を作ります。 embed_tcp_server と言う branch で、如何でしょうか？ 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 |
|
From: Takeru I. <tak...@gm...> - 2008-06-25 12:12:29
|
> では、諸々考慮しつつ、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...> |
|
From: masahito i. <coo...@gm...> - 2008-06-25 14:58:21
|
http://kai.svn.sourceforge.net/viewvc/kai?view=rev&sortby=log&revision=14 とりあえず、本日は、branch だけ追加しました。 branches の下に cooldaemon ディレクトリを作るのではなく cooldaemon_embed_tcp_server と言う branch を作りました。 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 |
|
From: masahito i. <coo...@gm...> - 2008-06-28 23:21:05
|
以下、ML に送り忘れていたので転送致します。 申し訳ございませんでした。（また、やってしまいました orz） >案としては、kai_config が Option オブジェクト(Config オブジェクト)を返すのも >ありかな？と思うのですが、如何でしょうか？ 上記、テストを書いていて、少し考え直しました。 ある一つのプロセスをテストする際 毎回、kai_config プロセスを起動する事になるので それよりは、各プロセスの init 時に Args を元に Config オブジェクトを new するか start_link 時に Config オブジェクト を Args として渡した方が 良い気がするのですが、如何でしょうか？ （起動の手間隙というより、プロセス間の依存を減らして 疎結合にした方が、テストしやすいなーと） ---------- Forwarded message ---------- From: masahito ikuta <coo...@gm...> Date: 2008/6/28 Subject: Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方] To: Takeru INOUE <tak...@gm...> kai_tcp_server というのを作った際 そこに渡されるオプションを管理する為に 勢い余って、下記のようなものを作ったのですが・・・ http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/src/kai_option.erl?view=markup&sortby=log&pathrev=16 kai_config の存在をスッカリ忘れてました。 という事で、kai_config を利用しようかと思うのですが gen_server なので、複数のプロセスからアクセスされると ボトルネックになりそうです。 頻繁にアクセスされないよう 取得したオプションを使い続けると言う手もあるのですが kai_tcp_server のように、Option オブジェクトを持ち回った方が コードは奇麗になりそうです。 案としては、kai_config が Option オブジェクト(Config オブジェクト)を返すのも ありかな？と思うのですが、如何でしょうか？ 2008/6/25 masahito ikuta <coo...@gm...>: > http://kai.svn.sourceforge.net/viewvc/kai?view=rev&sortby=log&revision=14 > とりあえず、本日は、branch だけ追加しました。 > > branches の下に cooldaemon ディレクトリを作るのではなく > cooldaemon_embed_tcp_server と言う branch を作りました。 > > 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 > -- cooldaemon -- cooldaemon |
|
From: shun s. <shi...@gm...> - 2008-06-29 07:12:52
|
しのはらです。 # ようやっと、ソース読みに手をつけはじめました。 2008/06/29 8:21 masahito ikuta <coo...@gm...>: >>案としては、kai_config が Option オブジェクト(Config オブジェクト)を返すのも >>ありかな？と思うのですが、如何でしょうか？ > > 上記、テストを書いていて、少し考え直しました。 > > ある一つのプロセスをテストする際 > 毎回、kai_config プロセスを起動する事になるので > それよりは、各プロセスの init 時に > Args を元に Config オブジェクトを new するか > start_link 時に Config オブジェクト を Args として渡した方が > 良い気がするのですが、如何でしょうか？ 賛成です。理由は、 > 疎結合にした方が、テストしやすいなーと） まさにこれにつきるとおもいます。 考慮すべき点としては、いまのところ、ひとつしか思いつかないのですが、 - 設定情報が動的に変更されるかどうか? これは今の kai.config にある設定であれば、静的なものが ほとんどかなぁ、と思ってますがどうでしょう? # これからの発展によって変わるのかもしれんが > 以下、ML に送り忘れていたので転送致します。 > 申し訳ございませんでした。（また、やってしまいました orz） (gmail だと?) つい、r で from/to のみに reply ってやってしまいますよね。。。 rubyforge の ML( mailman ) だと、ML の設定項目に、Reply-To: ヘッダを ML 宛に上書きする、っていうのがありました。 # 「できるだけ使うな」って注釈が付いてたんだけど 個人宛リプライが何度かあったので、めんどくさくなって、Reply-To: を ML に するように変更した記憶があります。 # ここまで書いてなんだけど、 sf.net は知りません m(_ _)m shino |
|
From: Takeru I. <tak...@gm...> - 2008-06-29 13:16:49
|
>>>案としては、kai_config が Option オブジェクト(Config オブジェクト)を返すのも
>>>ありかな？と思うのですが、如何でしょうか？
>>
>> 上記、テストを書いていて、少し考え直しました。
>>
>> ある一つのプロセスをテストする際
>> 毎回、kai_config プロセスを起動する事になるので
>> それよりは、各プロセスの init 時に
>> Args を元に Config オブジェクトを new するか
>> start_link 時に Config オブジェクト を Args として渡した方が
>> 良い気がするのですが、如何でしょうか？
>
> 賛成です。理由は、
>
>> 疎結合にした方が、テストしやすいなーと）
>
> まさにこれにつきるとおもいます。
性能面からは，kai_config のチューニングはまだ不要かなと思ってます．
kai_store も同じく．
一方で，kai_hash は一つの処理が 300ms を超え得ることがわかってるので，対策が必要です (これはすでに Tracker にある)．
ちなみに，kai_config で ets を使っている理由は，protected にすれば他のモジュールから読み取りできるようになるから．
この方法でも，特定のプロセスによる占有を回避できます．
ただし，そもそも ets 重いからやめようということがあるならダメですが．
次に，インターフェースの改良案についてです．
これは，
【現状】
test1(_Conf) ->
kai_config:start_link([{hostname, ....}]),
kai_hash:start_link(),
kai_store:start_link(),
のように書いているのを，
【案1】
test1(_Conf) ->
Conf = kai_config:start_link([{hostname, ...}]),
kai_hash:start_link(Conf),
kai_store:start_link(Conf),
のようにして kai_config オブジェクトを共有するというイメージでしょうか．
あるいは，
【案2】
-module(kai_hash).
init(Args) ->
% ...
{ok, [{config, kai_config:start_link(Args)}]}.
のようにして kai_config オブジェクトの複製を持つイメージでしょうか．
設定を動的に変更する予定はないですが，設定値というのはノード全体で共有されるのが素直な解釈なので，性能上の制約が明らかになるまでは【案2】のような複製は避けたほうが無難かなぁ．
そうしないと，忘れた頃に誰かがデバッグで苦労しそうな気がしました．
あとは，kai_config は実質的に singleton なので，【現状】と【案1】に違いはほとんどないような?
というわけで，kai_config のインターフェースを変更するメリットが分かってないわけですが，何か勘違いしてるかなぁ．
> 考慮すべき点としては、いまのところ、ひとつしか思いつかないのですが、
>
> - 設定情報が動的に変更されるかどうか?
>
> これは今の kai.config にある設定であれば、静的なものが
> ほとんどかなぁ、と思ってますがどうでしょう?
> # これからの発展によって変わるのかもしれんが
リファクタリングの定石からいくと，同時に複数の機能を追加・変更するのはなるべく避けたほうがいいでしょうか (というか，僕はそうするのが好みなだけかも)．
そうであれば，TCP server を書いて，すべてのテストが通るのをコミットしてから，kai_config を修正したほうがいいかも．
あるいは kai_config から先に修正するか．
--
Takeru INOUE <tak...@gm...>
|
|
From: masahito i. <coo...@gm...> - 2008-06-29 14:09:38
|
▼修正順について
・現在、 config はボトルネックとなっていない
・アプリケーション全体で、設定値を保持する箇所は一カ所にする
・同時に複数の機能を追加・変更するのはなるべく避けたほうがいい
という事に関して、全くその通りだと思うので、kai_config をそのまま使います。
▼イメージについて
まー、必要ないのですが、一応、補足です。
・現状
%..snip..
test1(_Conf) ->
kai_config:start_link([{hostname, "localhost"}, {port, 11011}, {n, 3},
{number_of_buckets, 8},
{number_of_virtual_nodes, 2}]),
kai_hash:start_link(),
%..snip..
・案
%..snip..
test1(_Conf) ->
kai_hash:start_link([{hostname, "localhost"}, {port, 11011}, {n, 3},
{number_of_buckets, 8},
{number_of_virtual_nodes, 2}]),
%..snip..
と考えてました。
で、init 時に
---
Config = kai_config:new(Args, DefaultArgs)
---
として、 Config を引き回し、実際に使う際に
---
Hostname = Config:get(hostname).
---
とするイメージでした。
2008/6/29 Takeru INOUE <tak...@gm...>:
>>>>案としては、kai_config が Option オブジェクト(Config オブジェクト)を返すのも
>>>>ありかな？と思うのですが、如何でしょうか？
>>>
>>> 上記、テストを書いていて、少し考え直しました。
>>>
>>> ある一つのプロセスをテストする際
>>> 毎回、kai_config プロセスを起動する事になるので
>>> それよりは、各プロセスの init 時に
>>> Args を元に Config オブジェクトを new するか
>>> start_link 時に Config オブジェクト を Args として渡した方が
>>> 良い気がするのですが、如何でしょうか？
>>
>> 賛成です。理由は、
>>
>>> 疎結合にした方が、テストしやすいなーと）
>>
>> まさにこれにつきるとおもいます。
>
> 性能面からは，kai_config のチューニングはまだ不要かなと思ってます．
> kai_store も同じく．
> 一方で，kai_hash は一つの処理が 300ms を超え得ることがわかってるので，対策が必要です (これはすでに Tracker にある)．
>
> ちなみに，kai_config で ets を使っている理由は，protected にすれば他のモジュールから読み取りできるようになるから．
> この方法でも，特定のプロセスによる占有を回避できます．
> ただし，そもそも ets 重いからやめようということがあるならダメですが．
>
> 次に，インターフェースの改良案についてです．
> これは，
>
> 【現状】
> test1(_Conf) ->
> kai_config:start_link([{hostname, ....}]),
> kai_hash:start_link(),
> kai_store:start_link(),
>
> のように書いているのを，
>
> 【案1】
> test1(_Conf) ->
> Conf = kai_config:start_link([{hostname, ...}]),
> kai_hash:start_link(Conf),
> kai_store:start_link(Conf),
>
> のようにして kai_config オブジェクトを共有するというイメージでしょうか．
> あるいは，
>
> 【案2】
> -module(kai_hash).
> init(Args) ->
> % ...
> {ok, [{config, kai_config:start_link(Args)}]}.
>
> のようにして kai_config オブジェクトの複製を持つイメージでしょうか．
>
> 設定を動的に変更する予定はないですが，設定値というのはノード全体で共有されるのが素直な解釈なので，性能上の制約が明らかになるまでは【案2】のような複製は避けたほうが無難かなぁ．
> そうしないと，忘れた頃に誰かがデバッグで苦労しそうな気がしました．
>
> あとは，kai_config は実質的に singleton なので，【現状】と【案1】に違いはほとんどないような?
>
> というわけで，kai_config のインターフェースを変更するメリットが分かってないわけですが，何か勘違いしてるかなぁ．
>
>> 考慮すべき点としては、いまのところ、ひとつしか思いつかないのですが、
>>
>> - 設定情報が動的に変更されるかどうか?
>>
>> これは今の kai.config にある設定であれば、静的なものが
>> ほとんどかなぁ、と思ってますがどうでしょう?
>> # これからの発展によって変わるのかもしれんが
>
> リファクタリングの定石からいくと，同時に複数の機能を追加・変更するのはなるべく避けたほうがいいでしょうか (というか，僕はそうするのが好みなだけかも)．
> そうであれば，TCP server を書いて，すべてのテストが通るのをコミットしてから，kai_config を修正したほうがいいかも．
> あるいは kai_config から先に修正するか．
>
> --
> 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
|
|
From: shun s. <shi...@gm...> - 2008-06-29 14:10:41
|
2008/06/29 22:16 Takeru INOUE <tak...@gm...>:
>>> 疎結合にした方が、テストしやすいなーと）
>>
>> まさにこれにつきるとおもいます。
>
> 性能面からは，kai_config のチューニングはまだ不要かなと思ってます．
「疎結合」が論点なんで、これは同意します。
> 一方で，kai_hash は一つの処理が 300ms を超え得ることがわかってるので，対策が必要です (これはすでに Tracker にある)．
それは大変だ :-<
> 【案1】
> test1(_Conf) ->
> Conf = kai_config:start_link([{hostname, ...}]),
> kai_hash:start_link(Conf),
> kai_store:start_link(Conf),
> 【案2】
> -module(kai_hash).
> init(Args) ->
> % ...
> {ok, [{config, kai_config:start_link(Args)}]}.
たしかにコードを出したほうがクッキリしますね。ありがとさん。
ぼくは、案2 です。
> 設定を動的に変更する予定はないですが，設定値というのはノード全体で共有されるのが素直な解釈なので，性能上の制約が明らかになるまでは【案2】のような複製は避けたほうが無難かなぁ．
> そうしないと，忘れた頃に誰かがデバッグで苦労しそうな気がしました．
今、コード読みはじめたばっかりなので、あまり大きなことは言えないですが、
常に設定サービスに問い合わせる場合、毎回同じあたいが返ってくるのか? ということを
考えながらコードを追いかけることになるので、不変なのであれば、それが
コード上で明確になればいいなぁ、とおもっていました。
# java なら final (ポインタの不変性) , Ruby なら定数(実は上書きできる) みたいなの
> リファクタリングの定石からいくと，同時に複数の機能を追加・変更するのはなるべく避けたほうがいいでしょうか (というか，僕はそうするのが好みなだけかも)．
> そうであれば，TCP server を書いて，すべてのテストが通るのをコミットしてから，kai_config を修正したほうがいいかも．
> あるいは kai_config から先に修正するか．
リファクタリングには機能の追加は含まれない、とか思想的なことはどうでもいいですが、
たしかに、構造の変更と、機能の追加は分離すべきだとおもいます。
ちょっとコード上の話にはまだきっちりついていてなくてすんません。
# 書いてる間にスレッドが更新されていく...
shino
|
|
From: Takeru I. <tak...@gm...> - 2008-06-29 14:20:41
|
>> 設定を動的に変更する予定はないですが，設定値というのはノード全体で共有されるのが素直な解釈なので，性能上の制約が明らかになるまでは【案2】のような複製は避けたほうが無難かなぁ． >> そうしないと，忘れた頃に誰かがデバッグで苦労しそうな気がしました． > > 今、コード読みはじめたばっかりなので、あまり大きなことは言えないですが、 > 常に設定サービスに問い合わせる場合、毎回同じあたいが返ってくるのか? ということを > 考えながらコードを追いかけることになるので、不変なのであれば、それが > コード上で明確になればいいなぁ、とおもっていました。 > # java なら final (ポインタの不変性) , Ruby なら定数(実は上書きできる) みたいなの それはそうだね． 僕は kai_config を書いた本人だから気にならないけど，他の人なら気になるかも． 実際，いくつかのモジュールでは設定値を変数に持ち直してループで繰り返し使っているところがある． これは，設定値が変更されないという前提があるからできてることだし． とはいえ final 的なことはできなそうだから，ドキュメントに "configuration values are never modified while running" とでも書いておくしかないかな． そして，「各プロセスでキャッシュしてよい」というルールにしたほうがいいのかなぁ． まぁ，細かいことだから神経質にならずにほっとくかぁ． >> リファクタリングの定石からいくと，同時に複数の機能を追加・変更するのはなるべく避けたほうがいいでしょうか (というか，僕はそうするのが好みなだけかも)． >> そうであれば，TCP server を書いて，すべてのテストが通るのをコミットしてから，kai_config を修正したほうがいいかも． >> あるいは kai_config から先に修正するか． > > リファクタリングには機能の追加は含まれない、とか思想的なことはどうでもいいですが、 > たしかに、構造の変更と、機能の追加は分離すべきだとおもいます。 > ちょっとコード上の話にはまだきっちりついていてなくてすんません。 > > # 書いてる間にスレッドが更新されていく... > > shino > -- Takeru INOUE <tak...@gm...> |
|
From: Takeru I. <tak...@gm...> - 2008-06-29 14:16:41
|
> ▼修正順について
> ・現在、 config はボトルネックとなっていない
> ・アプリケーション全体で、設定値を保持する箇所は一カ所にする
> ・同時に複数の機能を追加・変更するのはなるべく避けたほうがいい
>
> という事に関して、全くその通りだと思うので、kai_config をそのまま使います。
圧力っぽくなってたらごめんなさい＞＜
僕もあんまり正しい自信もないので，特に，後続の篠原のメールをみると別の観点からいまの kai_config はよろしくない点があるなぁと思いました．
> ▼イメージについて
> まー、必要ないのですが、一応、補足です。
>
> ・現状
> %..snip..
> test1(_Conf) ->
> kai_config:start_link([{hostname, "localhost"}, {port, 11011}, {n, 3},
> {number_of_buckets, 8},
> {number_of_virtual_nodes, 2}]),
> kai_hash:start_link(),
> %..snip..
>
> ・案
> %..snip..
> test1(_Conf) ->
> kai_hash:start_link([{hostname, "localhost"}, {port, 11011}, {n, 3},
> {number_of_buckets, 8},
> {number_of_virtual_nodes, 2}]),
> %..snip..
>
> と考えてました。
複製が発生するパターンですね．
> で、init 時に
> ---
> Config = kai_config:new(Args, DefaultArgs)
> ---
> として、 Config を引き回し、実際に使う際に
> ---
> Hostname = Config:get(hostname).
> ---
> とするイメージでした。
>
>
> 2008/6/29 Takeru INOUE <tak...@gm...>:
>>>>>案としては、kai_config が Option オブジェクト(Config オブジェクト)を返すのも
>>>>>ありかな？と思うのですが、如何でしょうか？
>>>>
>>>> 上記、テストを書いていて、少し考え直しました。
>>>>
>>>> ある一つのプロセスをテストする際
>>>> 毎回、kai_config プロセスを起動する事になるので
>>>> それよりは、各プロセスの init 時に
>>>> Args を元に Config オブジェクトを new するか
>>>> start_link 時に Config オブジェクト を Args として渡した方が
>>>> 良い気がするのですが、如何でしょうか？
>>>
>>> 賛成です。理由は、
>>>
>>>> 疎結合にした方が、テストしやすいなーと）
>>>
>>> まさにこれにつきるとおもいます。
>>
>> 性能面からは，kai_config のチューニングはまだ不要かなと思ってます．
>> kai_store も同じく．
>> 一方で，kai_hash は一つの処理が 300ms を超え得ることがわかってるので，対策が必要です (これはすでに Tracker にある)．
>>
>> ちなみに，kai_config で ets を使っている理由は，protected にすれば他のモジュールから読み取りできるようになるから．
>> この方法でも，特定のプロセスによる占有を回避できます．
>> ただし，そもそも ets 重いからやめようということがあるならダメですが．
>>
>> 次に，インターフェースの改良案についてです．
>> これは，
>>
>> 【現状】
>> test1(_Conf) ->
>> kai_config:start_link([{hostname, ....}]),
>> kai_hash:start_link(),
>> kai_store:start_link(),
>>
>> のように書いているのを，
>>
>> 【案1】
>> test1(_Conf) ->
>> Conf = kai_config:start_link([{hostname, ...}]),
>> kai_hash:start_link(Conf),
>> kai_store:start_link(Conf),
>>
>> のようにして kai_config オブジェクトを共有するというイメージでしょうか．
>> あるいは，
>>
>> 【案2】
>> -module(kai_hash).
>> init(Args) ->
>> % ...
>> {ok, [{config, kai_config:start_link(Args)}]}.
>>
>> のようにして kai_config オブジェクトの複製を持つイメージでしょうか．
>>
>> 設定を動的に変更する予定はないですが，設定値というのはノード全体で共有されるのが素直な解釈なので，性能上の制約が明らかになるまでは【案2】のような複製は避けたほうが無難かなぁ．
>> そうしないと，忘れた頃に誰かがデバッグで苦労しそうな気がしました．
>>
>> あとは，kai_config は実質的に singleton なので，【現状】と【案1】に違いはほとんどないような?
>>
>> というわけで，kai_config のインターフェースを変更するメリットが分かってないわけですが，何か勘違いしてるかなぁ．
>>
>>> 考慮すべき点としては、いまのところ、ひとつしか思いつかないのですが、
>>>
>>> - 設定情報が動的に変更されるかどうか?
>>>
>>> これは今の kai.config にある設定であれば、静的なものが
>>> ほとんどかなぁ、と思ってますがどうでしょう?
>>> # これからの発展によって変わるのかもしれんが
>>
>> リファクタリングの定石からいくと，同時に複数の機能を追加・変更するのはなるべく避けたほうがいいでしょうか (というか，僕はそうするのが好みなだけかも)．
>> そうであれば，TCP server を書いて，すべてのテストが通るのをコミットしてから，kai_config を修正したほうがいいかも．
>> あるいは kai_config から先に修正するか．
>>
>> --
>> 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
>
--
Takeru INOUE <tak...@gm...>
|
|
From: masahito i. <coo...@gm...> - 2008-06-29 14:22:18
|
> 圧力っぽくなってたらごめんなさい＞＜
いや、全く、そんな感じはしませんでしたよ？（w；
▼一点だけ、お願い
現在、get という I/F があり、これは下記のように使うのですが
---
Value = kai_config:get(key).
---
こんな I/F も、欲しいなぁと・・・
---
[Value1, Value2] = kai_config:get([key1, key2]).
---
細かい話で、申し訳ないのですが、ご検討をお願い致します。
2008/6/29 Takeru INOUE <tak...@gm...>:
>> ▼修正順について
>> ・現在、 config はボトルネックとなっていない
>> ・アプリケーション全体で、設定値を保持する箇所は一カ所にする
>> ・同時に複数の機能を追加・変更するのはなるべく避けたほうがいい
>>
>> という事に関して、全くその通りだと思うので、kai_config をそのまま使います。
>
> 圧力っぽくなってたらごめんなさい＞＜
> 僕もあんまり正しい自信もないので，特に，後続の篠原のメールをみると別の観点からいまの kai_config はよろしくない点があるなぁと思いました．
>
>> ▼イメージについて
>> まー、必要ないのですが、一応、補足です。
>>
>> ・現状
>> %..snip..
>> test1(_Conf) ->
>> kai_config:start_link([{hostname, "localhost"}, {port, 11011}, {n, 3},
>> {number_of_buckets, 8},
>> {number_of_virtual_nodes, 2}]),
>> kai_hash:start_link(),
>> %..snip..
>>
>> ・案
>> %..snip..
>> test1(_Conf) ->
>> kai_hash:start_link([{hostname, "localhost"}, {port, 11011}, {n, 3},
>> {number_of_buckets, 8},
>> {number_of_virtual_nodes, 2}]),
>> %..snip..
>>
>> と考えてました。
>
> 複製が発生するパターンですね．
>
>
>> で、init 時に
>> ---
>> Config = kai_config:new(Args, DefaultArgs)
>> ---
>> として、 Config を引き回し、実際に使う際に
>> ---
>> Hostname = Config:get(hostname).
>> ---
>> とするイメージでした。
>>
>>
>> 2008/6/29 Takeru INOUE <tak...@gm...>:
>>>>>>案としては、kai_config が Option オブジェクト(Config オブジェクト)を返すのも
>>>>>>ありかな？と思うのですが、如何でしょうか？
>>>>>
>>>>> 上記、テストを書いていて、少し考え直しました。
>>>>>
>>>>> ある一つのプロセスをテストする際
>>>>> 毎回、kai_config プロセスを起動する事になるので
>>>>> それよりは、各プロセスの init 時に
>>>>> Args を元に Config オブジェクトを new するか
>>>>> start_link 時に Config オブジェクト を Args として渡した方が
>>>>> 良い気がするのですが、如何でしょうか？
>>>>
>>>> 賛成です。理由は、
>>>>
>>>>> 疎結合にした方が、テストしやすいなーと）
>>>>
>>>> まさにこれにつきるとおもいます。
>>>
>>> 性能面からは，kai_config のチューニングはまだ不要かなと思ってます．
>>> kai_store も同じく．
>>> 一方で，kai_hash は一つの処理が 300ms を超え得ることがわかってるので，対策が必要です (これはすでに Tracker にある)．
>>>
>>> ちなみに，kai_config で ets を使っている理由は，protected にすれば他のモジュールから読み取りできるようになるから．
>>> この方法でも，特定のプロセスによる占有を回避できます．
>>> ただし，そもそも ets 重いからやめようということがあるならダメですが．
>>>
>>> 次に，インターフェースの改良案についてです．
>>> これは，
>>>
>>> 【現状】
>>> test1(_Conf) ->
>>> kai_config:start_link([{hostname, ....}]),
>>> kai_hash:start_link(),
>>> kai_store:start_link(),
>>>
>>> のように書いているのを，
>>>
>>> 【案1】
>>> test1(_Conf) ->
>>> Conf = kai_config:start_link([{hostname, ...}]),
>>> kai_hash:start_link(Conf),
>>> kai_store:start_link(Conf),
>>>
>>> のようにして kai_config オブジェクトを共有するというイメージでしょうか．
>>> あるいは，
>>>
>>> 【案2】
>>> -module(kai_hash).
>>> init(Args) ->
>>> % ...
>>> {ok, [{config, kai_config:start_link(Args)}]}.
>>>
>>> のようにして kai_config オブジェクトの複製を持つイメージでしょうか．
>>>
>>> 設定を動的に変更する予定はないですが，設定値というのはノード全体で共有されるのが素直な解釈なので，性能上の制約が明らかになるまでは【案2】のような複製は避けたほうが無難かなぁ．
>>> そうしないと，忘れた頃に誰かがデバッグで苦労しそうな気がしました．
>>>
>>> あとは，kai_config は実質的に singleton なので，【現状】と【案1】に違いはほとんどないような?
>>>
>>> というわけで，kai_config のインターフェースを変更するメリットが分かってないわけですが，何か勘違いしてるかなぁ．
>>>
>>>> 考慮すべき点としては、いまのところ、ひとつしか思いつかないのですが、
>>>>
>>>> - 設定情報が動的に変更されるかどうか?
>>>>
>>>> これは今の kai.config にある設定であれば、静的なものが
>>>> ほとんどかなぁ、と思ってますがどうでしょう?
>>>> # これからの発展によって変わるのかもしれんが
>>>
>>> リファクタリングの定石からいくと，同時に複数の機能を追加・変更するのはなるべく避けたほうがいいでしょうか (というか，僕はそうするのが好みなだけかも)．
>>> そうであれば，TCP server を書いて，すべてのテストが通るのをコミットしてから，kai_config を修正したほうがいいかも．
>>> あるいは kai_config から先に修正するか．
>>>
>>> --
>>> 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
>>
>
>
>
> --
> Takeru INOUE <tak...@gm...>
>
--
cooldaemon
|
|
From: Takeru I. <tak...@gm...> - 2008-06-29 14:31:37
|
>> 圧力っぽくなってたらごめんなさい＞＜
>
> いや、全く、そんな感じはしませんでしたよ？（w；
（^^;ゞ
> ▼一点だけ、お願い
> 現在、get という I/F があり、これは下記のように使うのですが
> ---
> Value = kai_config:get(key).
> ---
> こんな I/F も、欲しいなぁと・・・
> ---
> [Value1, Value2] = kai_config:get([key1, key2]).
> ---
> 細かい話で、申し訳ないのですが、ご検討をお願い致します。
戻り値は tuple のほうが使いやすかったりします?
引数はどうかなぁ．
get 関数の作りとしては List のがラクだけど，呼び出し側は tuple のがいいのかなぁ．
> 2008/6/29 Takeru INOUE <tak...@gm...>:
>>> ▼修正順について
>>> ・現在、 config はボトルネックとなっていない
>>> ・アプリケーション全体で、設定値を保持する箇所は一カ所にする
>>> ・同時に複数の機能を追加・変更するのはなるべく避けたほうがいい
>>>
>>> という事に関して、全くその通りだと思うので、kai_config をそのまま使います。
>>
>> 圧力っぽくなってたらごめんなさい＞＜
>> 僕もあんまり正しい自信もないので，特に，後続の篠原のメールをみると別の観点からいまの kai_config はよろしくない点があるなぁと思いました．
>>
>>> ▼イメージについて
>>> まー、必要ないのですが、一応、補足です。
>>>
>>> ・現状
>>> %..snip..
>>> test1(_Conf) ->
>>> kai_config:start_link([{hostname, "localhost"}, {port, 11011}, {n, 3},
>>> {number_of_buckets, 8},
>>> {number_of_virtual_nodes, 2}]),
>>> kai_hash:start_link(),
>>> %..snip..
>>>
>>> ・案
>>> %..snip..
>>> test1(_Conf) ->
>>> kai_hash:start_link([{hostname, "localhost"}, {port, 11011}, {n, 3},
>>> {number_of_buckets, 8},
>>> {number_of_virtual_nodes, 2}]),
>>> %..snip..
>>>
>>> と考えてました。
>>
>> 複製が発生するパターンですね．
>>
>>
>>> で、init 時に
>>> ---
>>> Config = kai_config:new(Args, DefaultArgs)
>>> ---
>>> として、 Config を引き回し、実際に使う際に
>>> ---
>>> Hostname = Config:get(hostname).
>>> ---
>>> とするイメージでした。
>>>
>>>
>>> 2008/6/29 Takeru INOUE <tak...@gm...>:
>>>>>>>案としては、kai_config が Option オブジェクト(Config オブジェクト)を返すのも
>>>>>>>ありかな？と思うのですが、如何でしょうか？
>>>>>>
>>>>>> 上記、テストを書いていて、少し考え直しました。
>>>>>>
>>>>>> ある一つのプロセスをテストする際
>>>>>> 毎回、kai_config プロセスを起動する事になるので
>>>>>> それよりは、各プロセスの init 時に
>>>>>> Args を元に Config オブジェクトを new するか
>>>>>> start_link 時に Config オブジェクト を Args として渡した方が
>>>>>> 良い気がするのですが、如何でしょうか？
>>>>>
>>>>> 賛成です。理由は、
>>>>>
>>>>>> 疎結合にした方が、テストしやすいなーと）
>>>>>
>>>>> まさにこれにつきるとおもいます。
>>>>
>>>> 性能面からは，kai_config のチューニングはまだ不要かなと思ってます．
>>>> kai_store も同じく．
>>>> 一方で，kai_hash は一つの処理が 300ms を超え得ることがわかってるので，対策が必要です (これはすでに Tracker にある)．
>>>>
>>>> ちなみに，kai_config で ets を使っている理由は，protected にすれば他のモジュールから読み取りできるようになるから．
>>>> この方法でも，特定のプロセスによる占有を回避できます．
>>>> ただし，そもそも ets 重いからやめようということがあるならダメですが．
>>>>
>>>> 次に，インターフェースの改良案についてです．
>>>> これは，
>>>>
>>>> 【現状】
>>>> test1(_Conf) ->
>>>> kai_config:start_link([{hostname, ....}]),
>>>> kai_hash:start_link(),
>>>> kai_store:start_link(),
>>>>
>>>> のように書いているのを，
>>>>
>>>> 【案1】
>>>> test1(_Conf) ->
>>>> Conf = kai_config:start_link([{hostname, ...}]),
>>>> kai_hash:start_link(Conf),
>>>> kai_store:start_link(Conf),
>>>>
>>>> のようにして kai_config オブジェクトを共有するというイメージでしょうか．
>>>> あるいは，
>>>>
>>>> 【案2】
>>>> -module(kai_hash).
>>>> init(Args) ->
>>>> % ...
>>>> {ok, [{config, kai_config:start_link(Args)}]}.
>>>>
>>>> のようにして kai_config オブジェクトの複製を持つイメージでしょうか．
>>>>
>>>> 設定を動的に変更する予定はないですが，設定値というのはノード全体で共有されるのが素直な解釈なので，性能上の制約が明らかになるまでは【案2】のような複製は避けたほうが無難かなぁ．
>>>> そうしないと，忘れた頃に誰かがデバッグで苦労しそうな気がしました．
>>>>
>>>> あとは，kai_config は実質的に singleton なので，【現状】と【案1】に違いはほとんどないような?
>>>>
>>>> というわけで，kai_config のインターフェースを変更するメリットが分かってないわけですが，何か勘違いしてるかなぁ．
>>>>
>>>>> 考慮すべき点としては、いまのところ、ひとつしか思いつかないのですが、
>>>>>
>>>>> - 設定情報が動的に変更されるかどうか?
>>>>>
>>>>> これは今の kai.config にある設定であれば、静的なものが
>>>>> ほとんどかなぁ、と思ってますがどうでしょう?
>>>>> # これからの発展によって変わるのかもしれんが
>>>>
>>>> リファクタリングの定石からいくと，同時に複数の機能を追加・変更するのはなるべく避けたほうがいいでしょうか (というか，僕はそうするのが好みなだけかも)．
>>>> そうであれば，TCP server を書いて，すべてのテストが通るのをコミットしてから，kai_config を修正したほうがいいかも．
>>>> あるいは kai_config から先に修正するか．
>>>>
>>>> --
>>>> 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
>>>
>>
>>
>>
>> --
>> Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>
--
Takeru INOUE <tak...@gm...>
|
|
From: shun s. <shi...@gm...> - 2008-06-29 14:51:39
|
2008/06/29 23:31 Takeru INOUE <tak...@gm...>: >>> 圧力っぽくなってたらごめんなさい＞＜ >> >> いや、全く、そんな感じはしませんでしたよ？（w； > > （^^;ゞ なんか、中途半端に返信してひっかきまわした気がするです。m(_ _)m まぁ、「kai_config を使う」という方向で決まったみたいで。 > とはいえ final 的なことはできなそうだから，ドキュメントに "configuration values are never > modified while running" とでも書いておくしかないかな． # そうだよねぇ、破壊的操作のない言語で final ってないよなぁ。。。 shino |
|
From: masahito i. <coo...@gm...> - 2008-06-30 08:37:34
|
下記のような使い方を想定してます。 http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/src/kai_tcp_server.erl?view=markup この source の 79 - 80 行目に下記のようなコードがあります。 --- [MaxConn, MaxRestarts, Time, Shutdown] = Option:get([max_connections, max_restarts, time, shutdown]), --- これは、kai_config:get/1 で記述しなおすと --- [MaxConn, MaxRestarts, Time, Shutdown] = lists:map(fun kai_config:get/1, [max_connections, max_restarts, time, shutdown]). --- となります。（※今、即興で書いたので動作検証してません） これを --- [MaxConn, MaxRestarts, Time, Shutdown] = kai_config:get([max_connections, max_restarts, time, shutdown]), --- と書けたら良いかな？と思いました。 利点としては、メッセージ送信の回数を減らせるのと 記述が少し短くなるという二点です。 kai_config の handle_call({get, Key}, _From, State) に ガード条件を加えて、Key が is_list だったら lists:map で、kai_config:get/2 を実行するイメージです。 2008/6/29 Takeru INOUE <tak...@gm...>: >>> 圧力っぽくなってたらごめんなさい＞＜ >> >> いや、全く、そんな感じはしませんでしたよ？（w； > > （^^;ゞ > >> ▼一点だけ、お願い >> 現在、get という I/F があり、これは下記のように使うのですが >> --- >> Value = kai_config:get(key). >> --- >> こんな I/F も、欲しいなぁと・・・ >> --- >> [Value1, Value2] = kai_config:get([key1, key2]). >> --- >> 細かい話で、申し訳ないのですが、ご検討をお願い致します。 > > 戻り値は tuple のほうが使いやすかったりします? > > 引数はどうかなぁ． > get 関数の作りとしては List のがラクだけど，呼び出し側は tuple のがいいのかなぁ． > > >> 2008/6/29 Takeru INOUE <tak...@gm...>: >>>> ▼修正順について >>>> ・現在、 config はボトルネックとなっていない >>>> ・アプリケーション全体で、設定値を保持する箇所は一カ所にする >>>> ・同時に複数の機能を追加・変更するのはなるべく避けたほうがいい >>>> >>>> という事に関して、全くその通りだと思うので、kai_config をそのまま使います。 >>> >>> 圧力っぽくなってたらごめんなさい＞＜ >>> 僕もあんまり正しい自信もないので，特に，後続の篠原のメールをみると別の観点からいまの kai_config はよろしくない点があるなぁと思いました． >>> >>>> ▼イメージについて >>>> まー、必要ないのですが、一応、補足です。 >>>> >>>> ・現状 >>>> %..snip.. >>>> test1(_Conf) -> >>>> kai_config:start_link([{hostname, "localhost"}, {port, 11011}, {n, 3}, >>>> {number_of_buckets, 8}, >>>> {number_of_virtual_nodes, 2}]), >>>> kai_hash:start_link(), >>>> %..snip.. >>>> >>>> ・案 >>>> %..snip.. >>>> test1(_Conf) -> >>>> kai_hash:start_link([{hostname, "localhost"}, {port, 11011}, {n, 3}, >>>> {number_of_buckets, 8}, >>>> {number_of_virtual_nodes, 2}]), >>>> %..snip.. >>>> >>>> と考えてました。 >>> >>> 複製が発生するパターンですね． >>> >>> >>>> で、init 時に >>>> --- >>>> Config = kai_config:new(Args, DefaultArgs) >>>> --- >>>> として、 Config を引き回し、実際に使う際に >>>> --- >>>> Hostname = Config:get(hostname). >>>> --- >>>> とするイメージでした。 >>>> >>>> >>>> 2008/6/29 Takeru INOUE <tak...@gm...>: >>>>>>>>案としては、kai_config が Option オブジェクト(Config オブジェクト)を返すのも >>>>>>>>ありかな？と思うのですが、如何でしょうか？ >>>>>>> >>>>>>> 上記、テストを書いていて、少し考え直しました。 >>>>>>> >>>>>>> ある一つのプロセスをテストする際 >>>>>>> 毎回、kai_config プロセスを起動する事になるので >>>>>>> それよりは、各プロセスの init 時に >>>>>>> Args を元に Config オブジェクトを new するか >>>>>>> start_link 時に Config オブジェクト を Args として渡した方が >>>>>>> 良い気がするのですが、如何でしょうか？ >>>>>> >>>>>> 賛成です。理由は、 >>>>>> >>>>>>> 疎結合にした方が、テストしやすいなーと） >>>>>> >>>>>> まさにこれにつきるとおもいます。 >>>>> >>>>> 性能面からは，kai_config のチューニングはまだ不要かなと思ってます． >>>>> kai_store も同じく． >>>>> 一方で，kai_hash は一つの処理が 300ms を超え得ることがわかってるので，対策が必要です (これはすでに Tracker にある)． >>>>> >>>>> ちなみに，kai_config で ets を使っている理由は，protected にすれば他のモジュールから読み取りできるようになるから． >>>>> この方法でも，特定のプロセスによる占有を回避できます． >>>>> ただし，そもそも ets 重いからやめようということがあるならダメですが． >>>>> >>>>> 次に，インターフェースの改良案についてです． >>>>> これは， >>>>> >>>>> 【現状】 >>>>> test1(_Conf) -> >>>>> kai_config:start_link([{hostname, ....}]), >>>>> kai_hash:start_link(), >>>>> kai_store:start_link(), >>>>> >>>>> のように書いているのを， >>>>> >>>>> 【案1】 >>>>> test1(_Conf) -> >>>>> Conf = kai_config:start_link([{hostname, ...}]), >>>>> kai_hash:start_link(Conf), >>>>> kai_store:start_link(Conf), >>>>> >>>>> のようにして kai_config オブジェクトを共有するというイメージでしょうか． >>>>> あるいは， >>>>> >>>>> 【案2】 >>>>> -module(kai_hash). >>>>> init(Args) -> >>>>> % ... >>>>> {ok, [{config, kai_config:start_link(Args)}]}. >>>>> >>>>> のようにして kai_config オブジェクトの複製を持つイメージでしょうか． >>>>> >>>>> 設定を動的に変更する予定はないですが，設定値というのはノード全体で共有されるのが素直な解釈なので，性能上の制約が明らかになるまでは【案2】のような複製は避けたほうが無難かなぁ． >>>>> そうしないと，忘れた頃に誰かがデバッグで苦労しそうな気がしました． >>>>> >>>>> あとは，kai_config は実質的に singleton なので，【現状】と【案1】に違いはほとんどないような? >>>>> >>>>> というわけで，kai_config のインターフェースを変更するメリットが分かってないわけですが，何か勘違いしてるかなぁ． >>>>> >>>>>> 考慮すべき点としては、いまのところ、ひとつしか思いつかないのですが、 >>>>>> >>>>>> - 設定情報が動的に変更されるかどうか? >>>>>> >>>>>> これは今の kai.config にある設定であれば、静的なものが >>>>>> ほとんどかなぁ、と思ってますがどうでしょう? >>>>>> # これからの発展によって変わるのかもしれんが >>>>> >>>>> リファクタリングの定石からいくと，同時に複数の機能を追加・変更するのはなるべく避けたほうがいいでしょうか (というか，僕はそうするのが好みなだけかも)． >>>>> そうであれば，TCP server を書いて，すべてのテストが通るのをコミットしてから，kai_config を修正したほうがいいかも． >>>>> あるいは kai_config から先に修正するか． >>>>> >>>>> -- >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Takeru INOUE <tak...@gm...> >>> >> >> >> >> -- >> cooldaemon >> > > > > -- > Takeru INOUE <tak...@gm...> > -- cooldaemon |
|
From: Tsukasa H. <ml...@cu...> - 2008-06-30 11:19:52
|
こんにちは、濱野です。 すっかり出遅れてしまいましたが、 1) accept した直後にプロセスを生成してコネクションを受け持つモデルと 2) 予め複数のプロセスを生成しておいて全て accept 待ちにしておく という２種類のモデルについて、思うところを書かせて頂きます。 まず、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 っぽくて萌えるのですがｗ；） > >> > >> 死活監視と接続最大数は別の話だとは思いつつも > >> 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...> > > ------------------------------------------------------------------------- > 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...> |
|
From: Takeru I. <tak...@gm...> - 2008-06-30 15:22:10
|
僕も，(1) と (2) の差はコードの簡潔さだと思います． 一般的なプログラミング言語では (1) で書くのが定石でしょうか． 一方 Erlang はプロセス間の相互作用の少ない (2) で書けるので，「せっかくだからそうしよう」というのが Kai の流れでしょうか． パフォーマンスは調べてみないとわかりませんが，accept 後の spawn/dispatch 的な処理を (1) 自分で書くのか (2) OTP にやらせるのかの違いかなと思ってます． まぁ，OTP はそんなに遅くないと都合良く信じることにして，(2) でいいかなと ^^; ってな風に考えてます． 2008/6/30 Tsukasa Hamano <ml...@cu...>: > こんにちは、濱野です。 > > すっかり出遅れてしまいましたが、 > > 1) accept した直後にプロセスを生成してコネクションを受け持つモデルと > 2) 予め複数のプロセスを生成しておいて全て accept 待ちにしておく > > という２種類のモデルについて、思うところを書かせて頂きます。 > > まず、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 っぽくて萌えるのですがｗ；） >> >> >> >> 死活監視と接続最大数は別の話だとは思いつつも >> >> 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...> >> >> ------------------------------------------------------------------------- >> 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...> > -- Takeru INOUE <tak...@gm...> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X