2011/07/22 Node.jsの勉強会 「『Node.js』とは何か。そして、その先へ。」 に行ってきました

「『Node.js』とは何か。そして、その先へ。」( http://www.jus.or.jp/benkyokai/11-07.html )
(日本Unixユーザ会の勉強会)のレポートです。

・日時
2011/07/22 18:30〜20:30

・講師
bad_at_mathさん、jackさん


資料が配布され、それに従った説明を聞く+サンプルを見る形でした。
下記は配布された資料に、説明内容+aを追記したものです内容です。

■Node.js

まずはNode.jsとは。
・サーバサイドJavaScriptプラットフォーム
・2009年、Ryan Dath作

■背景

そしてそのNode.jsはなぜ(何のために)誕生したか。
C10K問題
 -同時接続数が思い切り増えていくと、サーバがパンクしてしまう
 -従来型の1スレッド1コネクションで同期I/Oというモデルにて表面化

■マルチスレッドの問題

マルチスレッドには下記の問題がある。また、腕の良い開発者でないと実装は難しい(資源の共有による、デッドロックの問題など)

○コンテキストスレッド

スレッド切り替えによるコストもばかにならない。
レジスタからのデータI/Oだけでも秒間数万系発生したりすると、それだけで高負荷な処理となる。

○メモリ効率

・1スレッドあたり2MB以上であり、スレッドの処理内容によっては10MB以上の場合も
(2MBとか10MBとかの数字はどこから出たものなんだっけ。この時間、一瞬席周りがばたついて聞き逃したっぽい。。)

ブロッキングI/O

・読み取り、書き込みが完了するまでひたすら待ち続ける処理
・ディスクやネットワークからの読み取り、書き込み性能はメモリにくらべてかなり遅いので問題になる
このあたりはLAMPな人がぶちあたりがちな問題ですね。

○I/Oコスト

CPUのL1キャッシュ : 3サイクル
CPUのL1キャッシュ : 14サイクル
RAM : 250サイクル
ディスク : 41,000,000サイクル
ネットワーク : 240,000,000サイクル

○解決策

・I/O多重化
 -select()poll()など
・イベント駆動モデル
ノンブロッキングI/O
 ちなみに、ノンブロッキングI/Oと非同期I/Oって違うものなんですね。混同してた・・。ちゃんと勉強しよう。
 - http://togetter.com/li/136290
 - http://d.hatena.ne.jp/forest1040/20110407/1302150936

○select(),poll()

一度に多数のFD(ファイルディスクリプタ)の状態を確認可能

  • select()
    • サイズの決まったFDを書き出してカーネルに確認
  • poll()
    • 可変長配列にFDを書き出してカーネルに確認
○epoll

select()やpoll()・・・FDをstateはプログラム側で検査する必要がある
epollの・・準備のできたFDの集合が返される

■性能比

liveventのベンチ比較。epoll優秀

■イベント駆動モデル

・シングルスレッド+ループ
・発生イベントの無いようにより処理分岐
・計量
・古くからGUIライブラリなどでも利用
・シグナルもその1つと言える(?)

■ノンブロッキングI/O

・読み取り、書き込み処理を行うとその成功、終了を待たずに呼び元に戻る
・ブロックしないので、他の処理を続けることが可能

■HTTPサーバ実装例

・enginex
lighttpd

■ライブラリ実装例

・libevent
・libev

■libevent

・ver0.1は2001年リリース
・Liels Provos(現Google)作
・シングルスレッド
・イベント駆動
・ノンブロッキング
・mecached等で利用

■libev

・Marc Lehman(GCCのPen最適化)
・livenentよりも高性能(ver1.x比)

■各言語での実装例

・Twisted(Phthon)
・AnyEvent(Perl)
・EventMachine(Ruby)

■Ryan Dahl

・Edd(ruby製webサーバ)
・libebb(httpサーバライブラリ)

■オリジナル実装へ

・より高速へ
・よりスケーラブルに

■Node.jsリリース

・イベント周りにはlibevを利用
・ファイルI/Oにはlibeio
Google製JSエンジン(v8)
・自前のHTTPパーサ
・C-ares(非同期DNSライブラリ)

■特徴

・シングルスレッド
・非同期
・ノンブロッキングI/O

アーキテクチャ

Node.jsは、
v8、libev、libeioで構成されている。

JavaScript

・スレッドライブラリなし
・非同期プログラミング
・近年目覚しく高速化
 GoogleMapなどのAjaxやリッチなクライアント側実装に耐えうる各ブラウザベンダがしのぎをけずって高速化に取り組んだ
・開発者人口の多さ

■V8

JavaScriptを大幅にスピードアップ
 ・プロパティ・メソッドアクセス高速化
 ・高速かつオーバーヘッドの少ないJIT
 ・効率の良いGC

■libeio

・ファイルI/Oを受け持つ
・内部ではスレッドプールを利用

■Node.jsの利点

・高効率
・賞メモリ
・HTTPがファーストクラス
・多数の接続に対応
・クライアントからサーバまで一貫(JS)
 →どっちもJavaScriptで実装
・Webアプリ経験者の敷居の低さ
 →これもJavaScriptで実装していることによる
・利用可能なライブラリはnon-blocking
・各コンポーネントの高速化の恩恵にあずかれる
 ・V8、libev

■コード例

省略
(よくある、HTTPサーバをたててHello World出力)

■Server-Side JS

Node.jsだけでなく、下記のようなサーバサイドJSライブラリもある
・Ringo.js
・Pinture
・Joyent Smart
・Jaxer

■既存のものとの違い

・目的やバックグラウンドが違う
 ・Node.jsは高速性、また多くの接続をハンドリングできることを目標に作られている
 ・JSを採用したのは上記の条件を満たす部品としてマッチしたため。

■Node.jsの得意分野

・同時接続数が多く、計量な処理のもの
 ・リアルタイムアプリケーション

■Node.jsの欠点

・シングルスレッドであること
 ・マルチコアを生かし切れない
(一応、現時点でNode Clusterやプロセスを複数たちあげる方法も無くは無い)
 ・CPUインテンシブな処理は構造上苦手(ループを高速にまわす必要がある)
 ・V7noヒープが現状、64bitで1.9GB(32bitで1GB)
 ・モジュールは非常に多く存在するが完成度があと一歩のものが多い

■Node.jsの流儀

Every I/O uses Non-Blocking I/O
・他の言語では同期I/Oを利用するライブラリを使ってしまい、処理速度が落ちる可能性があるがNodeではそれがない

■必要とされるスキル

・非同期プログラミングスキル
 ・サーバサイドではそれほど一般的ではない

■Node.jsの現状

・Windoesサポートに向けて、Microsoftが協力を表明(今ではバイナリ配布も)
・メジャープラットフォーム全てにおいて動作

■libuv

Windows版Node.jsはv8エンジンと、libuvで構成されている。
libuv…WindowsでNode.jsを機能させる為のIOライブラリ?(ここ、ちょっと理解しきれませんでした。また調べます)


ここでbad_at_mathさん講師の前半が終了

後半はjackさんによる実際のインストール〜アプリ作成まで。
また別の日に書く。かも。