kai-devel-ja Mailing List for kai (Page 11)
Kai is a distributed key-value datastore
Status: Beta
Brought to you by:
takemaru
Menu
▾
▴
kai-devel-ja — For Kai developers in Japanese
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(95) |
Jul
(94) |
Aug
(44) |
Sep
(5) |
Oct
(8) |
Nov
(14) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(18) |
Mar
(19) |
Apr
|
May
(11) |
Jun
(8) |
Jul
(4) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
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: 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: 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: 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: 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: 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: 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: Takeru I. <tak...@gm...> - 2008-06-25 11:48:56
|
> コーディング規約にソフトタブで 4 つって書いてたよね、たしか? そうっす＞＜ > そこに、tips として、 emacs の erlang-mode だったらこうしたらいいよ、 > みたいなのはあっていいとおもう。 という話題になったので，コーディング規約についてちょっと書いてみます． Wiki にそれっぽいことが書いてあります． http://kai.wiki.sourceforge.net/development+resources Wiki では下記の文書を紹介しています． http://www.erlang.se/doc/programming_rules.pdf これは，コーディング規約というより，「モジュール間の依存性を減らす (特に循環)」などの設計ルールも含めたお作法一覧です． この文章の粗っぽい日本語メモを公開しておきます． http://teahut.sakura.ne.jp/b/2008-06-25-2.html # この文章が Erlang の一般的なコーディング規約と思ってよいのでしょうか? コーディング規約といっても，堅苦しく考えないでください． 規約が気になってコードが書けなくなっては本末転倒なので，厳しく管理するつもりはないです． 僕が無視してたのがよい例です (いや，悪い例だけど…)． 徐々に慣れていけばいいと思います． また，この文章が完全というわけではないので，やりにくい部分があれば修正していきましょう． ところで，紹介した文章にはありませんでしたが，Wiki にはインデントと関数の並び順について書いてあります． インデントは，yaws や ejabberd, couchdb で 4スペースだったので，そのように書いておきました (いや，自分がタブを使ってたわけですが…)． 関数の並び順については，いまみると適切ではないし，そこまで規定しないでもいいだろうという気がするので，消しておこうと思います． # ちなみに，関数の並び順について次のように書いていました． In a module file, difinitions and functions are ordered like: * -behaviour, -export, -include, -record, -define * start, init, terminate * functions doing normal jobs * callbacks * functions called from other process > On 6/25/08 2:01 AM Takeru INOUE wrote: >> ありがとー． >> 直しておきます． > > 老婆心ながら、 M-x untabify で f(--) > > 今日くらいから、ソース読み始めるかも > そしたら、分からんところ ML で相談するねー > -- 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 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: shinohara <shi...@gm...> - 2008-06-25 00:45:19
|
コーディング規約にソフトタブで 4 つって書いてたよね、たしか?
そこに、tips として、 emacs の erlang-mode だったらこうしたらいいよ、
みたいなのはあっていいとおもう。
例えば、 linux kernel の配布物には、./Documentaion/CodingStyle というファイルに
(defun linux-c-mode ()
"C mode with adjusted defaults for use with the Linux kernel."
(interactive)
(c-mode)
中略
(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
auto-mode-alist))
のようなサンプルがのっている。 # こっちは、auto-mode-alist でやってるな、さすがに汎用的だ
On 6/25/08 2:01 AM Takeru INOUE wrote:
> ありがとー．
> 直しておきます．
老婆心ながら、 M-x untabify で f(--)
今日くらいから、ソース読み始めるかも
そしたら、分からんところ ML で相談するねー
|
|
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-24 17:07:42
|
>> http://kai.wiki.sourceforge.net/getting+started >> >> # じつは，一次情報はこの Wiki なんです :-) > > では、I/F に変更がある場合は > こちらを修正するように致します。 気がついたらでいいですよ． ドキュメントは僕が面倒見るつもりでいるので． > ちなみに、Makefile から yrl の箇所も削除してしまいました。 > yecc を使う際には、また追加する方向で（汗 いらないでしょう． なくなってるのに気づきませんでしたw > 2008/6/23 Takeru INOUE <tak...@gm...>: >>> http://kai.svn.sourceforge.net/viewvc/kai?view=rev&sortby=log&revision=13 >>> 初 commit してみました・・・。 >>> 至らない点が多々あるかと思いますので、指摘等よろしくお願い致します。 >> >> ありがとうございます． >> >> .beam が src/ から ebin/ に移動になったので，Wiki にある実行方法を修正しておきました． >> >> http://kai.wiki.sourceforge.net/getting+started >> >> # じつは，一次情報はこの Wiki なんです :-) >> >>> ▼trunk/ebin/.gitignore >>> いきなり言い訳で申し訳ないのですが >>> trunk/ebin/.gitignore を Add してしまい >>> 申し訳ございませんでした。 >>> （git で空ディレクトリを作る為に配置してしまいました。 >>> 後で、他を commit する際に、こっそり消します。） >> >> そのへんは実害もないですし，気にしないでいいと思いますよ． >> >>> ▼src/kai.app.src >>> 本来は、commit log に残すべき内容なのですが >>> 記述を忘れてしまったので、こちらで説明をさせて下さい。 >>> （今後は、commit log に書きます ） >> >> commit log をどこまで詳しく書くかってのも悩ましいですよね． >> 概要だけわかれば，詳細は diff をみるなり本人に問い合わせるなりすればわかるので，それなりに書いてあればいいかも? >> (自分が詳しく書きたくないだけという説もある) >> >>> make 時に sed を使って kai.app.src 内の %VSN% を >>> Makefike 内の KAI_VSN で置き換えています。 >>> >>> 将来的に、kai コマンド (kai.sh ?) を作った際 >>> KAI_VSN を含めるかなぁ？と思い勝手にやってしまいました。 >> >> ぜんぜん考えてませんでしたが，いいと思います． >> バージョンアップするときは，src/Makefile の番号を修正するのですね? >> >>> 適当に、0.1.0 とかにしています。 >>> branch を作った後に >>> 0.1.0 [branch name] とかにすると良いかも？ >> >> バージョン番号も 0.1.0 で適当だと思います． >> >> >>> 2008/6/23 masahito ikuta <coo...@gm...>: >>>> ありがとうございます。 >>>> svn の commit が可能か否かの確認として >>>> 今晩、対応させて頂きます。 >>>> >>>> 2008/6/23 Takeru INOUE <tak...@gm...>: >>>>>> とても細かい話で申し訳ないのですが・・・ >>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので >>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？ >>>>>> （autotools に対応する気力は無いのですが orz） >>>>> >>>>> はい，素晴らしいと思います :-) >>>>> >>>>> ディレクトリ構造や make 周りは，僕のいい加減さがよく表れてしまってます．． >>>>> ぼちぼちと直していきますが，正しい Erlang の流儀を知っている方がいましたら遠慮なくやっちゃってください． >>>>> >>>>> >>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 > > > > -- > 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 > -- Takeru INOUE <tak...@gm...> |
|
From: Takeru I. <tak...@gm...> - 2008-06-24 17:06:57
|
# kai-devel-ja が宛先から落ちてたけど，間違いだと思ってよいのかな? >> 詳細がわからないので何ともいえませんが，なにやら勝てそうな気がしてきます :-) > > Erlang は、この手の問題を解決する為の DSL ですから > 汎用言語に負けたくないですね Twitter で勝てそう宣言したら， http://twitter.com/takemaru_jp/statuses/842174596 Erlang 勉強会に来てた @kzk_mover さんから応援が来ましたw http://twitter.com/kzk_mover/statuses/842205777 >> 最大の難関はテスト環境の確保かもしれません… > > イベントネタになりますけど > 勉強会の際に、参加者の NotePC 上で複数ノードを起動して > いろいろ観察してみる等、如何でしょうか？ それで軽めのテストというのはいいですね． 何時間も動かせるテスト環境もいずれは欲しくなるでしょうが，後で考えましょう． > 2008/6/24 Takeru INOUE <tak...@gm...>: >> たけまるです． >> >> RubyKaigi での Matz の基調講演で，楽天の ROMA/fairy が少しだけ紹介されてました． >> >> まつもとさんの基調講演 その3（RubyKaigi2008）‐ニコニコ動画(SP1) >> http://www.nicovideo.jp/watch/sm3726943 >> >> ROMA は GFS みたいなものだろうと思っていたのですが，どうやら Dynamo っぽいですね． >> >> # GFS はテラバイト級の巨大ファイル向きで，Dynamo は小さな無数のデータ向き． >> # アーキテクチャはまるっきり違う． >> >> 開発を始めてから一年くらい経つはずですが，あまり進んでないようです． >> Matz は「6台のマシンで 10ノードが動作した」と言っていました． >> >> 詳細がわからないので何ともいえませんが，なにやら勝てそうな気がしてきます :-) >> 手元の環境では，2台のマシンで 16ノードは動作しています (大した負荷はかけてませんが)． >> Merkle tree などを導入してデータの同期を高速化できれば，30-50 ノードくらいはそんなに難しくないと思ってます >> (50ノードくらいなら Chord はなくても ok)． >> >> 最大の難関はテスト環境の確保かもしれません… >> >> -- >> 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: Takeru I. <tak...@gm...> - 2008-06-24 17:01:35
|
ありがとー． 直しておきます． こういう細かいことも Wiki に書いておいた方がよいのだろうか? 一種のコーディング規約みたいなものだけど． 2008/6/24 shinohara <shi...@gm...>: > そうだっけ? > デフォルトで使ってるけど、ソフトになってるはずだ?? > あー、グローバルにソフトタブ使うようにしているかも。 > .emacs からコピペ > > ;;;; erlang settings > (add-to-list 'load-path "~/.emacs.d/erlang") > (require 'erlang-start) > (add-hook 'erlang-mode-hook 'erlang-font-lock-level-3) > (add-hook 'erlang-mode-hook > '(lambda () > (progn > (define-key erlang-mode-map "\C-m" 'reindent-then-newline-and-indent) > (setq indent-tabs-mode nil) ;; ここが erlang-mode でのソフトタブな設定 > (setq tab-width 4) > ))) > > こんなかんじやねー > 参考になれば > > On 6/23/08 11:26 PM Takeru INOUE wrote: >>> - いくつか、ソースコード中にハードタブ(0x09)がありました >> >> 「デフォルトの emacs erlang-mode がそうしてるんだ」というのは言い訳ですが， >> 篠原も emacs 使ってると思うんだけど，untabify な erlang-mode に修正してる? >> > -- Takeru INOUE <tak...@gm...> |
|
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: 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: shinohara <shi...@gm...> - 2008-06-24 00:46:11
|
そうだっけ?
デフォルトで使ってるけど、ソフトになってるはずだ??
あー、グローバルにソフトタブ使うようにしているかも。
.emacs からコピペ
;;;; erlang settings
(add-to-list 'load-path "~/.emacs.d/erlang")
(require 'erlang-start)
(add-hook 'erlang-mode-hook 'erlang-font-lock-level-3)
(add-hook 'erlang-mode-hook
'(lambda ()
(progn
(define-key erlang-mode-map "\C-m" 'reindent-then-newline-and-indent)
(setq indent-tabs-mode nil) ;; ここが erlang-mode でのソフトタブな設定
(setq tab-width 4)
)))
こんなかんじやねー
参考になれば
On 6/23/08 11:26 PM Takeru INOUE wrote:
>> - いくつか、ソースコード中にハードタブ(0x09)がありました
>
> 「デフォルトの emacs erlang-mode がそうしてるんだ」というのは言い訳ですが，
> 篠原も emacs 使ってると思うんだけど，untabify な erlang-mode に修正してる?
>
|
|
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-23 23:33:13
|
下記メールを、kai-devel-ja に送り忘れたので転送します。 申し訳ございません。 ---------- Forwarded message ---------- From: masahito ikuta <coo...@gm...> Date: 2008/6/24 Subject: Re: [Kai-devel-ja] ディレクトリ構造 [was Re: 開発の進め方] To: Takeru INOUE <tak...@gm...> > http://kai.wiki.sourceforge.net/getting+started > > # じつは，一次情報はこの Wiki なんです :-) では、I/F に変更がある場合は こちらを修正するように致します。 ちなみに、Makefile から yrl の箇所も削除してしまいました。 yecc を使う際には、また追加する方向で（汗 2008/6/23 Takeru INOUE <tak...@gm...>: >> http://kai.svn.sourceforge.net/viewvc/kai?view=rev&sortby=log&revision=13 >> 初 commit してみました・・・。 >> 至らない点が多々あるかと思いますので、指摘等よろしくお願い致します。 > > ありがとうございます． > > .beam が src/ から ebin/ に移動になったので，Wiki にある実行方法を修正しておきました． > > http://kai.wiki.sourceforge.net/getting+started > > # じつは，一次情報はこの Wiki なんです :-) > >> ▼trunk/ebin/.gitignore >> いきなり言い訳で申し訳ないのですが >> trunk/ebin/.gitignore を Add してしまい >> 申し訳ございませんでした。 >> （git で空ディレクトリを作る為に配置してしまいました。 >> 後で、他を commit する際に、こっそり消します。） > > そのへんは実害もないですし，気にしないでいいと思いますよ． > >> ▼src/kai.app.src >> 本来は、commit log に残すべき内容なのですが >> 記述を忘れてしまったので、こちらで説明をさせて下さい。 >> （今後は、commit log に書きます ） > > commit log をどこまで詳しく書くかってのも悩ましいですよね． > 概要だけわかれば，詳細は diff をみるなり本人に問い合わせるなりすればわかるので，それなりに書いてあればいいかも? > (自分が詳しく書きたくないだけという説もある) > >> make 時に sed を使って kai.app.src 内の %VSN% を >> Makefike 内の KAI_VSN で置き換えています。 >> >> 将来的に、kai コマンド (kai.sh ?) を作った際 >> KAI_VSN を含めるかなぁ？と思い勝手にやってしまいました。 > > ぜんぜん考えてませんでしたが，いいと思います． > バージョンアップするときは，src/Makefile の番号を修正するのですね? > >> 適当に、0.1.0 とかにしています。 >> branch を作った後に >> 0.1.0 [branch name] とかにすると良いかも？ > > バージョン番号も 0.1.0 で適当だと思います． > > >> 2008/6/23 masahito ikuta <coo...@gm...>: >>> ありがとうございます。 >>> svn の commit が可能か否かの確認として >>> 今晩、対応させて頂きます。 >>> >>> 2008/6/23 Takeru INOUE <tak...@gm...>: >>>>> とても細かい話で申し訳ないのですが・・・ >>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので >>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？ >>>>> （autotools に対応する気力は無いのですが orz） >>>> >>>> はい，素晴らしいと思います :-) >>>> >>>> ディレクトリ構造や make 周りは，僕のいい加減さがよく表れてしまってます．． >>>> ぼちぼちと直していきますが，正しい Erlang の流儀を知っている方がいましたら遠慮なくやっちゃってください． >>>> >>>> >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 -- cooldaemon |
|
From: Takeru I. <tak...@gm...> - 2008-06-23 15:53:43
|
たけまるです． RubyKaigi での Matz の基調講演で，楽天の ROMA/fairy が少しだけ紹介されてました． まつもとさんの基調講演 その3（RubyKaigi2008）‐ニコニコ動画(SP1) http://www.nicovideo.jp/watch/sm3726943 ROMA は GFS みたいなものだろうと思っていたのですが，どうやら Dynamo っぽいですね． # GFS はテラバイト級の巨大ファイル向きで，Dynamo は小さな無数のデータ向き． # アーキテクチャはまるっきり違う． 開発を始めてから一年くらい経つはずですが，あまり進んでないようです． Matz は「6台のマシンで 10ノードが動作した」と言っていました． 詳細がわからないので何ともいえませんが，なにやら勝てそうな気がしてきます :-) 手元の環境では，2台のマシンで 16ノードは動作しています (大した負荷はかけてませんが)． Merkle tree などを導入してデータの同期を高速化できれば，30-50 ノードくらいはそんなに難しくないと思ってます (50ノードくらいなら Chord はなくても ok)． 最大の難関はテスト環境の確保かもしれません… -- Takeru INOUE <tak...@gm...> |
|
From: Takeru I. <tak...@gm...> - 2008-06-23 14:26:00
|
> - いくつか、ソースコード中にハードタブ(0x09)がありました 「デフォルトの emacs erlang-mode がそうしてるんだ」というのは言い訳ですが， 篠原も emacs 使ってると思うんだけど，untabify な erlang-mode に修正してる? -- Takeru INOUE <tak...@gm...> |
|
From: Takeru I. <tak...@gm...> - 2008-06-23 14:24:30
|
> strict な事は行ってませんが、プレゼン資料に掲載されている操作は大丈夫です。 よかったです． >> fink な環境でコケました > > 私は、Common Test のマイナーバージョンがちょっと古いので > そこだけ書き換えました。(1.3.0 -> 1.3.1) > ※OSX 10.4.11 では、1.3.0、1.3.1 両方は入っているので修正無し > > Mochiweb LT で Common Test 必須みたいな言い方をしたのですが > 利用者の中には、run_test コマンドを生成していない方もいらっしゃるので・・・ > しばらくは、利用者に make test を実行させないという方針でも良いかも？ > と個人的には思ってますが、如何でしょうか？ そうですね． ./configure などで自動解決されるまでは，Wiki の Getting Started ページから削除しておきます． # CouchDB とか他のプロジェクトをみれば参考になるかな? > ところで、蛇足ではありますが > Common Test 用の coverspec ファイルを用意しても良いですか？ > これを準備しておくと Code Coverage Analysis が利用可能になります。 はい，いいと思います． 本格的な感じがしますね :-) > 2008/6/23 shun shino <shi...@gm...>: >> しのはらです。 >> >> 2008/06/22 21:34 Takeru INOUE <tak...@gm...>: >>> みなさんのところでそれなりに動いているようでしたら，最初のリリースをしようと思います． >>> 機能的にはシンプルなものなので，大きな反響を期待できるかはわかりませんが． >> >> まだ、ソースをチラ見しかできていないですが f(--) >> こまかーい点でコメントだけです。 # べつにリリースするのに障害になるようなもんでもないが >> - いくつか、ソースコード中にハードタブ(0x09)がありました >> - common_test の実行ファイルが、MacPorts 流になってて、 >> fink な環境でコケました >> これはどうやるんすかね? やっぱ configure なんでしょうか? >> #環境変数くらいで逃げれれば楽そう、とか言ってたら深みにハマるかな?? >> >> ではー >> >> shino >> >> ------------------------------------------------------------------------- >> 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-23 14:23:38
|
> http://kai.svn.sourceforge.net/viewvc/kai?view=rev&sortby=log&revision=13 > 初 commit してみました・・・。 > 至らない点が多々あるかと思いますので、指摘等よろしくお願い致します。 ありがとうございます． .beam が src/ から ebin/ に移動になったので，Wiki にある実行方法を修正しておきました． http://kai.wiki.sourceforge.net/getting+started # じつは，一次情報はこの Wiki なんです :-) > ▼trunk/ebin/.gitignore > いきなり言い訳で申し訳ないのですが > trunk/ebin/.gitignore を Add してしまい > 申し訳ございませんでした。 > （git で空ディレクトリを作る為に配置してしまいました。 > 後で、他を commit する際に、こっそり消します。） そのへんは実害もないですし，気にしないでいいと思いますよ． > ▼src/kai.app.src > 本来は、commit log に残すべき内容なのですが > 記述を忘れてしまったので、こちらで説明をさせて下さい。 > （今後は、commit log に書きます ） commit log をどこまで詳しく書くかってのも悩ましいですよね． 概要だけわかれば，詳細は diff をみるなり本人に問い合わせるなりすればわかるので，それなりに書いてあればいいかも? (自分が詳しく書きたくないだけという説もある) > make 時に sed を使って kai.app.src 内の %VSN% を > Makefike 内の KAI_VSN で置き換えています。 > > 将来的に、kai コマンド (kai.sh ?) を作った際 > KAI_VSN を含めるかなぁ？と思い勝手にやってしまいました。 ぜんぜん考えてませんでしたが，いいと思います． バージョンアップするときは，src/Makefile の番号を修正するのですね? > 適当に、0.1.0 とかにしています。 > branch を作った後に > 0.1.0 [branch name] とかにすると良いかも？ バージョン番号も 0.1.0 で適当だと思います． > 2008/6/23 masahito ikuta <coo...@gm...>: >> ありがとうございます。 >> svn の commit が可能か否かの確認として >> 今晩、対応させて頂きます。 >> >> 2008/6/23 Takeru INOUE <tak...@gm...>: >>>> とても細かい話で申し訳ないのですが・・・ >>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので >>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？ >>>> （autotools に対応する気力は無いのですが orz） >>> >>> はい，素晴らしいと思います :-) >>> >>> ディレクトリ構造や make 周りは，僕のいい加減さがよく表れてしまってます．． >>> ぼちぼちと直していきますが，正しい Erlang の流儀を知っている方がいましたら遠慮なくやっちゃってください． >>> >>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> 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-23 13:57:14
|
> 激しく雑談の領域に近づきつつあり > 申し訳ないのですが・・・ > >> ただ，Dynamo に Kademlia が合うかどうかは真面目に検討してないので，実際に実装する前には厳密に評価したほうがいいでしょうね． > > 評価基準すら理解していないので > とりあえず興味の赴くまま、Chord、Kademlia 両方勉強しておき > いざと言う時に、意見を言えるようにしておきます。 おぉ，頼もしいです． DHT に consistency や transaction を絡められると，勉強会 (あるいは学会) として成り立つかも． >> このへんの技術を勉強するのであれば，P2P教科書 がそれなりにまとまっています (技術分類などに問題のある本ですが)． > > ありがとうございます！ > > http://www.amazon.co.jp/P2P%E6%95%99%E7%A7%91%E6%9B%B8-%E3%82%A4%E3%83%B3%E3%83%97%E3%83%AC%E3%82%B9%E6%A8%99%E6%BA%96%E6%95%99%E7%A7%91%E6%9B%B8%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA-%E6%B1%9F%E5%B4%8E-%E6%B5%A9/dp/4844325043 > > これですよね？ これです． > 今晩、早速、本屋さんへ行ってきま〜す。 > > 2008/6/23 Takeru INOUE <tak...@gm...>: >>> ありがとうございます！ >>> kai_membership.erl の実装に関わる自信はありませんが・・・ >>> 今のところ、一番興味のある箇所なので >>> ご指導の程、宜しくお願い致します。 >>> （私のような初心者が、学んだ事をアウトプットする事で >>> Kai プロジェクト参加の敷居を下げる効果が >>> あるのではないかなぁと・・・） >>> >>> ところで、興味本位の質問ではあるのですが >>> 幾つかある DHT のアルゴリズムの中から >>> Kai では Chord を採用した理由を >>> 差し支えなければ、お教え頂けないでしょうか？ >> >> Kai としては DHT のアルゴリズムを決めてはないのですが， >> Dynamo が Chord を選択した理由は次のようなものだと思います． >> >> - DHT アルゴリズムの中では簡単だった (Pastry とかより簡単) >> - Dynamo 開発当初は Kademlia がまだなかったか，一定の評価が与えられてなかった >> >> 最近だと BitTorrent に採用されていることもあって，Kademlia の評価が高いのかなぁ． >> >> 僕としては，Kai に実装するなら Chord か Kademlia のどちらかだろうと思ってます． >> 先のメールに書いたように，すでに Kademlia の Erlang 実装があるので，やや Kademlia に傾いてるかな． >> >> ただ，Dynamo に Kademlia が合うかどうかは真面目に検討してないので，実際に実装する前には厳密に評価したほうがいいでしょうね． >> >> このへんの技術を勉強するのであれば，P2P教科書 がそれなりにまとまっています (技術分類などに問題のある本ですが)． >> >> >>> 2008/6/22 Takeru INOUE <tak...@gm...>: >>>> 井上 (たけまる) です． >>>> >>>>> ▼要望 >>>>> たけまるさんのプレゼンで、DHT に興味を持ちました。 >>>>> >>>>> 現在は、Chord について、いろいろ調べたり >>>>> 少しだけ試しに実装してみて試行錯誤している段階です。 >>>>> >>>>> そこで、どこかの段階で、Chord について理解している事をまとめたり >>>>> Erlang で書いたコードを晒したりするので >>>>> たけまるさん初め有識者の方々のご指導を頂きたいのですが >>>>> 如何なものでしょうか？ >>>> >>>> はい，よろこんで． >>>> >>>> DHT は Erlang に適していると思うのですが，実装はそれほど多くないかもしれません． >>>> 少し調べてみたところ，id:ytakano さん (ご存じの方います?) の Kademlia と， >>>> >>>> Erlangで分散ハッシュテーブルを実装してみた - NO!と言えるようになりたい >>>> http://d.hatena.ne.jp/ytakano/20080507/1210136628 >>>> >>>> 先週の Conference on Scalability というところで発表のあった Chord with transaction がヒットしました． >>>> >>>> YouTube - Seattle Conference on Scalability: Scalable Wikipedia with E >>>> http://jp.youtube.com/watch?v=pW339qR7DvU&feature=user >>>> >>>> -- >>>> Takeru INOUE <tak...@gm...> >>>> >>> >>> -- >>> cooldaemon >>> >> >> >> >> -- >> Takeru INOUE <tak...@gm...> >> > > > > -- > cooldaemon > -- Takeru INOUE <tak...@gm...> |
