Re: [Kai-devel-ja] stats
Kai is a distributed key-value datastore
Status: Beta
Brought to you by:
takemaru
Menu
▾
▴
Re: [Kai-devel-ja] stats
|
From: Takeru I. <tak...@gm...> - 2009-03-15 12:59:56
|
kai_tcp_server の testcase4 が失敗しています．
bad_info:4
どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
Mac Ports の Erlang です．
cooldaemon さんのところではどうでしょうか．
2009/3/15 Takeru INOUE <tak...@gm...>:
> 2009/3/15 masahito ikuta <coo...@gm...>:
>> kai_tcp_server から curr_connections を取得できるようになりましたので
>> お知らせ致します。
>
> お疲れ様でしたー．
>
>> 少し Source が汚れたのでリファクタリングした後
>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>> stat を触る上で注意点などありましたら
>> お教え頂けますでしょうか？
>
> 特にないです．
> curr_items の後にでも追加してください．
>
>> （例えば、curr_connections という名前じゃない方が良いなど）
>
> memcache と同じく curr_connections でいいんじゃないでしょうか．
>
>
>> よろしくお願いします。
>>
>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>> まだ時期尚早のようですね．．
>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>
>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>> 補足ですが・・・
>>>> Package を利用しているモジュール全てに
>>>> -import(ets).
>>>> を追加すると、テストは全てパスします。
>>>>
>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>> Coverage log からソースコードが参照できないので
>>>> （Covered (%) 等は表示されています）
>>>> 利用は見送ろうと考えました。
>>>>
>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>> 落としどころが多々あります。
>>>>
>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>
>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>> Package を試してみました。
>>>>>
>>>>> 結論から先に述べると
>>>>> ファイル分割は行いますが
>>>>> Package 対応は止めようと思います。
>>>>>
>>>>> 実際に kai を起動して手動テストを行うと
>>>>> 正常に動作するのですが
>>>>> Common Test が Package と相性が悪いようで
>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>
>>>>> === ERROR! init_per_testcase crashed!
>>>>> Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>> Reason: {undef,
>>>>> [{'kai_tcp_server.ets',update_counter,
>>>>> [cover_internal_data_table,
>>>>> {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>> 1]},
>>>>> {'kai_tcp_server.sup',start_link,4},
>>>>> {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>> {test_server,my_apply,3},
>>>>> {test_server,init_per_testcase,3},
>>>>> {test_server,run_test_case_eval1,4},
>>>>> {test_server,run_test_case_eval,6}]}
>>>>>
>>>>> Common Test のカバレッジを管理する cover というモジュールの中で
>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>
>>>>> んー、残念。
>>>>>
>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>
>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>
>>>>>>> では、Package を採用してみます。
>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>
>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>
>>>>>>> まだ、コードを追ってませんが
>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>
>>>>>>> stats を trunk に Merge を確認した後
>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>
>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>
>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>
>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>
>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>
>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>
>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>> kai_store.erl
>>>>>>>>> kai_store/dets.erl
>>>>>>>>> kai_store/ets.erl
>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> 井上です．
>>>>>>>>>>
>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>
>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>
>>>>>>>>>> kai_tcp.sup:start()
>>>>>>>>>>
>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>
>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> 皆様
>>>>>>>>>>>
>>>>>>>>>>> 幾田です。
>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>
>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>
>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>
>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>
>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>
>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>
>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>
>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>
>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>
>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>
>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>
>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>
>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>
>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>
>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>
>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>
>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>
>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>
>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>> Kai...@li...
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>> Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
> Takeru INOUE <tak...@gm...>
>
--
Takeru INOUE <tak...@gm...>
|