NodeをApache上でCGIとして動かすというのはナンセンスなんでしょうか？
内村幸一郎
先月号のWeb+DBプレスの記事でNode.jsの記事を読み勉強し始めました。
http://nodejs.jp/
の記事を上から順にざっとよんで、
今はThe Node Beginner Bookを読んでいるところです。
Nodeの最初の印象としては、
nodeコマンドでJavaScriptがサーバ上のスクリプト言語として使えるといったことで、
JavaScriptでコマンドラインツールを書いたりできるんだなぁということでした。
その延長で考えていたんでWebアプリを作るとしたらnodeスクリプトをCGIとして
動かすのかなぁと思っていたんですが、いろんな導入記事などをよむと
Webサーバとしての機能から作るものが多く、先ほどの小堤さまのメールを読むと
むしろWebサーバの機能から作ることが普通という印象を受けました。
そこで質問なんですが、NodeをApache上でCGIとして動かすのはナンセンスなんでしょうか？
Nodeという世界において筋が悪い考えかたなのかなぁ、と思い始めました。
まだまだAPIなどもろくに覚えていない新参者で、もしおかしなことを言っていたり、
話にならないということであれば申し訳ありません。
勉強したいので、参考になる記事などを教えていただけると助かります。
JavaScriptについては一応オライリーの5版を一通り読んで（マスターしたとは言えませんが。。）
jQueryをユーザとして使える程度の勉強はしています。
以上、よろしくお願いいたします。
Jxck
- Node を CGI で動かすことはできます。
- ナンセンスかと言われると、ナンセンス
Toshihiro Shimizu
僕もJxckの意見に同意します。CGIで動かすならNodeであるメリットがないですね。
ちなみに、FastCGIなら https://github.com/billywhizz/node-fastcgi-parser とかもあったりします。
また、ちょっと前に話題になった https://www.fluxflex.com/ も、
Node.jsを動かす際には Apache + FastCGI で動かす仕組みであり、
そのためにかなりイレギュラーなことをしなくてはなりません。
2011/9/10 Jxck <block.rxc...@gmail.com>:
--
Toshihiro Shimizu / @meso
小林秀和
敢えてApache+Node(CGI)という構成のメリットを挙げるならば、既にPHPやPerlなどで構築されているシステムに、最小限の修正でNodeを導入できることでしょうか。
ただ、他の方々が仰る通り、そのようなことをするとNodeのメリットが失われてしまうのでNode導入の意味はなく、結局元も子もないのですが。
個人的に、WebSocketなどでコネクションを張り続けるようなプログラムを動かせなくなるのはとても大きな損失だと思います。
余談ですが、CGIとしてJavaScriptを動かしたいのであれば、fcgi-v8というものがあった気がします。
2011年9月10日13:40 Toshihiro Shimizu <shimizu....@gmail.com>:
内村幸一郎
Jxck さま
meso さま
KOBA789 さま
ご回答ありがとうございました。
質問の意図としては、「実際にCGIやApacheでNodeを動かしてみたい」
ということではなく、Nodeが何者なのか？何がこれまでと違うのか？何が面白いのか？
ということを考えていくなかで、今私の中にあるわかりやすい概念と比較することで
Nodeに迫っていけるのではないかということでした。
皆様のご回答を読むとサーバ上で動くJavaScriptスクリプトを単体のプロセスとして
動かし、Perlスクリプトやシェルスクリプト同様標準入出力をインターフェースとして
プログラミングできるプログラミング環境だということだということは
言えるのかなぁと思いました。
そして、node スクリプトをApacheで動かすのは可能だが筋の悪いことなんですね。
この辺はもっとNodeが何者なのかがつかめてくるまでは私にはわからないこと
だと思います。
質問の後、ウェブ検索したりしてなんとなく把握したのは、ご回答の中にもあるように
特定の問題領域でNodeが提供する環境が役に立つということなのかなぁという事です。
まだまだその問題領域についての理解が浅く、そういう意味でNodeのメリットを
理解し切れていません。
perl コマンドなどの従来のプログラミング環境と比べると、node コマンドが
提供するプログラミング環境はイベント駆動プログラミング環境を手軽に
（標準で）利用できる環境であり、IOがブロックしない環境であり、
そういった環境が強力に後押しできる問題領域があるってことなんですよね。
そこをちゃんと理解できたら、Webアプリケーションに限らず日々の業務を
効率化するスクリプティングにnode コマンドを活用することもできるんだろうなぁ
と思いました。
もう少し勉強続けてみます。
ありがとうございました。
Kyoji KATO
こんにちは、加藤（xkyoji）です
内村さんと一緒で、割と最近になってからNode.jsを知ったので、わたしの理解が参考になればと思って横から書くと、ご質問にある意図というのは、おそらくPerlやシェルなど他言語と比較するのではなく、Node.jsをApacheと比べられた方が、先に書かかれているJxckさん、mesoさん、KOBA789さんの内容、それにノンブロッキングI/Oといった特定分野の理解も進み易そうな印象があります。
例ですが、ここのページではベンチマークをApache+PHPとNode.jsでとっています。
http://code.google.com/p/node-js-vs-apache-php-benchmark/wiki/Tests
それと、Node.jsを理解するため私の場合は検索エンジン経由でいろいろな方のブログなどを見て公開されている記事を読んだり、あとGithubなどで公開しているソースや、nodeknockoutのアプリなどをいじったりしながら少しづつ理解をしていってます。
以上、ご参考になれば幸いです。
atsuya
nodeはサーバを作るためのフレームワークなので、perlだとcatalyst、rubyだとrailsやeventmachine、pythonだとtwistedなんかがnodeの比較対象としては相応だと思います。サーバを作るためのフレームワークで、尚且つ非同期APIを提供しているものとなると、eventmachineとtwistedがよりよい比較対象になると思います。
nodeをapache httpserverのcgiを経由して走らせるのは、passengerを使ってrailsをapache
httpserverで走らせるのが、より近い比較対象になると思います。
- 高木
2011/9/11 Kyoji KATO <mpdm....@googlemail.com>:
内村幸一郎
高木さま
内村です。
ご意見ありがとうございました！
Nodeとよくサンプルになっている、Webアプリケーションの実装までを、
apache+ApacheAPIアプリ,apache+mod_perl(+catalyst),apache+mod_php
などを同列に考える、そのうえで比較するということはわかるんですが、
Nodeはサーバを作るためのフレームワークというのは言い過ぎのような気がしました。
単にapacheとapache上の他のプログラミング言語で作成したWebアプリ
では困難な問題がNodeでそのまま作るWebアプリなら解決可能で、
そこに多くの方の興味が向いているということであって、
（まあ、もっともそれがほとんどの人がフォーカスしているという事なのかもしれませんが、
まだそこまで理解できていません。。）
NodeをWebアプリと必ずしも紐付ける必要はないと思っています。
あくまでも、JavaScript実行環境の実装の一つですよね。
Perlでも非同期IOの実装がありますし、Webサーバ実装もあるんで、
非同期IOを使うということとWebサーバを作るということは可能だと思います。
それらを組み合わせた実装があれば、それとの比較がNode+Webアプリ
のよくあるサンプルとの比較になるのかなぁと思いました。
Perl非同期Webアプリを作る上での困難とNode非同期Webアプリでのそれ、
Perl非同期Webアプリでの性能上の問題とNodeでのそれ、
といった比較をするとよくわかるのかなぁ。
ちょっと今ググった感じでは、AnyEvent(Perl)とNodeを置き換えるというような
こともあるみたいなんで、何かAnyEventで問題があってNodeだと解決する、
みたいなことがあるんでしょうね。
ということは、イベント駆動プログラミング環境を提供する各実装において、
Nodeが他の環境ではなしえていないことをしていて、
そこにたいしてNodeアプリケーション（Webアプリに限らず）を開発する
っていう考え方をしていけばいいんだろうか。
まとまりがなくてすみません、なんか変なこといってたらご指摘ください。
--
2011年9月12日8:20 atsuya <asoft...@gmail.com>:
Nobu Hatano
はじめまして、波多野と申します。
実は node.js 初心者ですが、自分なりの理解の仕方も何かの
ご参考になればと思いレスさせて頂きます。
多数のリクエストを同時にハンドリングするのに向いている
非同期 I/O のサーバーは、より前面に出ることで真価を
発揮すると考えれば、理解しやすいのかなと私なりに
考えています。なので node.js = Web サーバーだと。
さらに言えば、静的なファイルは nginx にまかせて、
動的なところを node にするとか、いい所を集めると、
そういう構成になってくるのかと思います。
一方 Apache 配下のスクリプト実行エンジンとして node.js を
見た場合、せっかくの利点を活かしにくいので評価するのが
難しいかと思います。実際、単体で階乗計算などの数値計算を
させた場合（私の組み方が悪いような気もしますが）
Rhino の方が処理が若干速いようです。
波多野
2011/9/12 内村幸一郎 <koichiro...@gmail.com>:
内村幸一郎
内村です。
> 非同期 I/O のサーバーは、より前面に出ることで真価を
> 発揮すると考えれば、理解しやすいのかなと私なりに
前面に出るというのは受信するところからイベント駆動の
環境で処理するということですよね。
それができないApache+nodeスクリプト真価が発揮できない
ということは、これまでの皆様のご意見とも合わせましても納得いたしました。
> 考えています。なので node.js = Web サーバーだと。
ごめんなさい、ここはどうしてもまだ納得できません。
イベント駆動、ブロックしないIOというプログラミング環境=Node
という理解です、今のところ。
ちなみに、不勉強で申し訳ありませんが、
nginxっていのは、イベント駆動のWebサーバなんですよね？
そこにもし、mod_nodeみたいなのがあったら、
いいのかな。あ、でもIOがブロックしたりするのかな。
webサーバとしてポート80で何かが立ち上がっているとして、
そこでいろいろなものを提供しないといけないときって、
Nodeだとどうするんですかね。
当初の疑問も、そういう観点から出てきたんだと思います。
Nodeにルーティングするモジュールがやっぱりあるんでしょうね、きっと。
そうなると、リバースプロキシで受けて、Nodeサーバと通常のWebサーバ
に振り分けるみたいなことになるんですかね。
なんかまとまりなくってすみません。
いろいろなご意見いただいて、Node脳を形成するいい刺激になってます。
--
2011年9月12日16:20 Nobu Hatano <nobuh...@gmail.com>:
Maki-Daisuke
はじめまして、牧と申します。
AnyEventとnode.jsの両方使った経験から言わせてもらいますと、プログラミング
のパラダイム的には同じですし、こちらでないとできないということは基本的には
ありません。
しかし、node.jsの利点は、その設計からnon-blocking I/Oにフォーカスして作ら
れているということです。
既存の処理系は通常、ブロッキングblocking I/Oをデフォルトとして捉え、その
前提もとでパフォーマンスが出るようにランタイムが設計・実装されています。
（実際、Javaではblocking I/Oのほうが性能が良いのだという調査結果もあります↓
http://www.thebuzzmedia.com/java-io-faster-than-nio-old-is-new-again/
）
それに対し、node.jsはnon-bloking I/Oをデフォルトとして、そのパフォーマン
スが最大となるようにしているのです。
また、node.jsではモジュール群も、non-blocking I/Oをデフォルトとして開発さ
れているのも大きなアドバンテージですね。
たとえば、PerlでAnyEventで開発を始めても、使いたい他のモジュールが中で
blocking I/Oをしてしまっていたりして、いらない手間が必要になったり必要に
なったりします。
実際問題として、そこまでのスケーラビリティが要求されるような大規模サービ
スを構築する必要があるのは、一握りの企業かと思います。
また、イベント駆動型プログラミングはスレッドプログラミングに比べて煩雑だ
と言われているので、パフォーマンスと実装コストのトレードオフもあります。
そのため、適材適所で使うものであって、無理に使うものではありません。
> イベント駆動、ブロックしないIOというプログラミング環境=Node
> という理解です、今のところ。
自分もその認識です。
しかし、最近の傾向から、当然主な目的はWebにならざるを得ませんので、
HTTP関係のAPIが最初からついてきます。
そのため、node.js＝Webサーバと言い切ってしまっても、大きく間違ってはいな
いのかもしれませんね。
> webサーバとしてポート80で何かが立ち上がっているとして、
> そこでいろいろなものを提供しないといけないときって、
> Nodeだとどうするんですかね。
ひとつのポートで複数のサービス（機能）をホスティングしたいという場合は、
素直にリバースプロクシを使うのが良いと思います。
サービスの独立性のためにも、安全性のためにも、それぞれ別プロセス／別マシ
ンで動かしたいですものね。
でも、Apacheの上で、とか、手前にnginxを置いて……と考える前に、全部
node.jsでやってしまったほうが早い、ということもありますよｗ
ちょうど、Node.jsで書かれたリバースプロクシもありますので、これを使えば
WebSocketsも怖くありません→ https://github.com/nodejitsu/node-http-proxy
node.js自身は、スケーラブルなネットワークプログラムを"効率的に"書ける環境
を目指して開発されています。
たとえば私のケースだと、つい最近、node.jsで簡単なジョブキューとワーカーの
プログラムを作成して、Amazon EC2上で136コア使って並列計算させるというような
ことを一日でやりました。
これを機会に、「なんでもnode.js」で始めてみてはいかがですか？ｗ
----
From: MAKI, Daisuke
twitter: http://twitter.com/Maki_Daisuke
nobuh...@gmail.com
どうも波多野です。牧さまや、他の方々からの色々な情報興味深いですよね。こうしてやり取りしてみると、私にとってもとても勉強になると感謝しています。
私も今まで仕入れた情報から、Node.js は Web サーバーで使う、リクエストをルーティングさせる、WebSocket みたいにリアルタイムで接続する、のが定石みたいな考えが有りました。しかし良く考えてみると、非同期 I/O は複数のDBや外部サイトへ同時アクセスしながら何かやる場合にも有益かもしれません。普通に作ると PHP とかの方が性能が良さそうですが、あえて CGI 的なバックエンドで node を使うのも新たな発見があるかもしれません。
"なんでも Node.js" でやって見るのがもしかしたら一番面白いのかもしれませんね。
波多野
内村幸一郎
内村です。
AnyEventとnode.jsの比較大変わかりやすかったです。
あるパラダイムを後押しする環境が違うってことなんですね。
「なんでもnode.js」ですか。
まあ、実装コストうんぬんとかをそれほどシビアに考える必要のない
自分プロジェクトで遊んでみます。
それ以外もいろいろと教えていただきありがとうございました。
2011年9月13日22:11 Maki-Daisuke <maki.d...@gmail.com>: