「来月までに勉強してきますねー」といってわかれたのに全然勉強してないなー、と後ろめたい気持ちで日曜日に恵比寿に行ったら、第一回に比べてものすごい勢いで人が減ってた件。ひどい！

でも、相変わらず実装・運用している人のはなしがずいぶん聞けて勉強になった。「Comet といえば」感のある Lingr とかね。以下時系列順じゃなくて話題ごとに並べ直しているので注意。

Erlang

• 実際に見てみたけど、前回の予想はそんなに外れてなかった。
• 魔法は無い。
• 配布されている tarball が最近でかくなったのは、コンパイル済みの中間コードも同梱されるようになったから。
• Erlang ってもともと UNIX 育ちではないよね
  • MD110 という交換機むけのシステムに書かれたらしい
  • epoll とか使ってるの? → grep するぶんにはあったよ
• Erlang のプロセス (!= UNIX プロセス) は軽い
  • Ruby のスレッドは重いよね
  • Matzにっき(2007-06-05) にあった Rubinius の8バイト以下ってなんだろね
  • 8バイトじゃなんもはいんなくね
• YAWS 関係なく HTTPd やってみた
  • httpd.erl
  • gen_tcp は listen するときに {packet, http} とわたすと、HTTP のリクエストの parse とか中でやってくれる
  • パターンマッチとかは関数型っぽいけど、けっこう普通に書ける
  • ループも car とって cdr わたして再帰とかせずに lists:foreach でさっくり

C10K の後

• 瀧内さんが書いてるので簡単に。
• イベントをうけるクライアント側が遅いとイベントキューが溢れるのでなんとかしたい
• producer-consumer パターンではありがち
  • consumer を増やす: スケールアウト
  • consumer を速く: スケールアップ
• TCP のアルゴリズムとかみればいいのでは
  • SACK (Selective ACK) とか
• LightStreamer は遅いクライアントに対してはイベントを間引いている。チャットではそうはいかないだろうけど、株価とか、値の上書きがあるシステムではうまくいく。まさにストリーミング。

Shooting Star

• Flash クライアントを書きました
  • HTTP ではないけどプロキシ通れるようポートは80番
  • つなぎっぱってプロキシ通れるのかな
  • HTTP 偽装したほうが通れるプロキシ増えるかな
• 非公式Wiki を作りました
• チャンネルの下にタグが持てて、これでイベントの配信範囲を区切れる
  • alis だと x, y 座標で区切ったり
  • チャンネルは接続に対応しているのでインスタンスを生成しなきゃいけないけど、タグはそういうの無いので軽く使える。GoF でいうところの Flyweight パターン。
• Asteroid のメソッドの名前とかは Ruby/EventMachine 由来
  • 最初は Ruby/EventMachine ですますつもりだった
• タグのマッチングに良いアルゴリズムってないのかな
  • タグを素数で、複数のタグを素数の積で表して mod をとる
  • 面白いけど、速くはなさそう
• signature ってなんですか
  • ユーザー識別用の値です
  • タイムスタンプなので、同じブラウザ上でもタブごとに別に扱える
  • タイムスタンプってかぶらない?
    • シングルスレッドだからかぶらない
    • UUID も接続がすごい増えたりすると、かぶるときはなぜかかぶるよ
• dRuby やめようよ
  • やめるのはそんなに大変じゃない
  • RESTful にできる?
  • REST だと毎回接続切ることになるから、サーバサイドでイベント通知するのに使うのは無駄が多い。
  • チャンネルにいる人数とか情報取得系なら REST であると良いかも。

Jetty

• Jetty にはライブラリとして実装された「継続」があるよ
  • 実行時例外を投げてフレームワーク側でつかんでおくとか、わりと大変なことになっている
• 外から使う分には楽
• Lingr は Jetty やめちゃった

Lingr

• RubyKaigi でのスポンサーセッション で話したはなしを基本に
• スレッド:ソケット = 1:1 はダメ。IO 多重化の方法が重要。
• 1 スレッド + ブロッキング IO: むり
• 1 スレッド + ノンブロッキング IO: よい
  • epoll に全部いれて見たいけどライブラリの中のものとかは無理
  • スレッドのスイッチは当然おこらない
  • 1 CPU で下手に 2 スレッド動かすより全然良い
• マルチスレッド、1 aceppter, 複数の worker: あんまりよくない
  • worker ごとに epoll → fd ひとつなので poll で良い
  • ソケットごとに worker あてると、結局リソース消費がはげしくなる
  • 複数ソケットを worker にあてるとか
• マルチスレッド、複数の accepter, worker: 意味がない
• kqueue は write の完了が通知されないような。レベルトリガなので仕様じゃなくてバグだと思う。
• Lingr はイベント、というか発言の内容も Comet サーバーが配信する。ここは Shooting Star とはちがう。
• クラスタリングしているサーバーのうち一台が死んだとき
  • クライアントID mod 台数だと、台数がかわると全部のクライアントが移動になる
  • となりのサーバーに移すと、となりのサーバーだけ負荷が倍になる
  • なにか良いものはないものか
  • それ CARP (Cache Array Routing Protocol) でできるよ