- 「DOMAINS & ISOLATES」 @koichikさん
- 2011/07 - コアチーム入りしてます
- 安定版の歴史、今後の予定
- v0.8 2012/01 リリース予定
- V8のリリースサイクルに合わせて頻繁なリリースを目指す
- 新機能の目玉がDomain, Isolates
- 現在絶賛開発中です
- エラーハンドリングの話
- AdventCalendarで書きました http://d.hatena.ne.jp/koichik/20111213#1323753316
- 粒度
- EventEmitterは細かすぎる
- processは大雑把すぎる
- そこでDomains
- 関連するイベントをまとめる
- net, dns, fs, timers
- "domains.createDomain(arg, cb)"
- ドメインのエラー処理
- ドメインに関連付けられたものを処理
- "myDomain.on('error', function (err) { ... })"
- 各種API
- Domainsまとめ
- 関連するI/Oをまとめることができる
- エラー処理をまとめたり
- まとめてキャンセルしたり
- 課題
- どのように構成するか?のノウハウ
- Isolates
- Isolatesまとめ
- V8 Isolateでマルチスレッド利用可能に
- 課題
- アドオンのマルチスレッド対応
- 質疑
- Q. 使い分け方法は?
- A. 障害極小化も考えるとリソースに懸念なければマルチプロセスで、スレッドはそんなに使わないほうが良いのでは
- 「Cloud Foundryで transports{['websocket']} 動かしてみた」 こまつけんさく(@komasshu)さん
- http://www.slideshare.net/KensakuKOMATSU/111214-node-conf
- HTML5, WebSocket
- Cloud Foundryとは
- http://www.cloudfoundry.com/
- VMWareが提供しているオープンソースPaaS
- Herokuみたいなサービスを自分で作れる
- Architecture of Cloud Foundry
- 様々なモジュールにより構成
- モジュール間はメッセージバス
- WebSocketとは
- まぁご存知ですよね
- Web上で動くVPNと考えています
- FW, Proxyを越えてくれる
- ただしHTTP/1.1への完全準拠が必要
- CloudFoundryではWebSocketが動かない
- nginx, routerが前にいる
- nginx
- tcp_proxyのpatchをあてれば良い
- router
- ハンドシェイクは通るがその後のFrameが通らない、という挙動
- そのあたりをカットするようにしてやれば良い
- 実際にこれで動かせました
- さらにいろいろやりたい が spec足りない
- のでrouterだけ切り出したり
- Githubに上げてます!
- BDD(Benkyo-kai Driven Development)!
- 質疑
- nginxのtcp_proxyについて
- 「『SlideStream』の紹介とリアルタイムWebのTips」 @Jxck_さん
- http://jxck.node-ninja.com/slides/nodeacademy3.html
- Chrome or Firefoxで見てね
- SlideStream
- https://github.com/Jxck/SlideStream
- based on deck.js
- realtime coding (codestream)
- realtime executing (shellstream)
- Paging
- socket.ioのAuthentication, Authorizationつかって話者のみ動かす
- adminとしてログインした人だけがbroadcast
- 認証大事!
- なんでもかんでもbroadcastしてしまわないように注意
- event名を知ってれば誰でも動かせる、などの形にしないように
- Steal the TTY
- How to display Editor
- auto-save-buffers 0.1秒ごとに自動保存
- watchFileもMacだと遅いので500msごとに監視
- 大事なのは「リアルタイム*に見えること*」
- 体感できれば十分
- diffを送ることについて
- volatileが重要
- 情報落ちの場合のことを考えるくらいなら全部送ってしまえ
- 発覚したbottle neck: ブラウザのメモリ
- イベントでコード更新する毎にhighlight
- もともとは一回だけの表示のためのものだから
- 必要なときだけhighlightするよう手を入れたw
- サーバでhighlightも考えたけど、ここはclientでやるべき、と判断
- IO heavy / CPU Heavy の処理のバランスを考えるのが大事
- 負荷テストの結果
- single process + Redis
- 500 - 1000 connections
- メモリ食い尽くさずに安定してイケた!
- Streamについて
- AdventCalendarに書いたよ http://d.hatena.ne.jp/Jxck/20111204/1322966453
- socketstream, flatironとかあるよね
- 今後のNodeで重要な要素だと思います