大きなファイルをレスポンスするようなものは、node.jsに向かない？

[アウゼン]

こんにちは、アウゼンです

初歩的な質問で、恐縮ですが

「大きなファイルをレスポンスするようなものは、node.jsに向かない」という話をよく耳にするのですが

どうして向かないのでしょうか？

下記のような500MBのファイルをレスポンスするソース(極端な例)で試してみましたが、fs.readFileもresponseもブロックする訳でもなく

どういうことなのか疑問に思っています。

var fs = require('fs');

var http = require('http');

http.createServer(function (req, res) {

    fs.readFile('/home/mongo/testdata500mb',function(err,data){

        console.log('responce start!!');

        res.writeHead(200, {'Content-Type': 'image/jpeg' } );

        res.end( data, 'binary' );

        console.log('responce end!!');

    });

}).listen(1337);

実際のところソースを動かして確認してみるとうまく動作しないという状況でした。

Apache benchで並行度(Concurrency Level)を1から4にあげていくと、3移行でリクエストが失敗してしまっています。

結果からはレスポンスが欠落しているように見えるのですが、これが向かない理由につながるのでしょうか？

Document Length:        524288000 bytes

Concurrency Level:      1

Complete requests:      1

Failed requests:        0

Time taken for tests:   44.293 seconds

Total transferred:      524288101 bytes

Requests per second:    0.02 [#/sec] (mean)

Time per request:       44292.662 [ms] (mean)

Time per request:       44292.662 [ms] (mean, across all concurrent requests)

Concurrency Level:      2

Complete requests:      2

Failed requests:        0

Time taken for tests:   88.648 seconds

Total transferred:      1048576202 bytes

Requests per second:    0.02 [#/sec] (mean)

Time per request:       88648.204 [ms] (mean)

Time per request:       44324.102 [ms] (mean, across all concurrent requests)

Concurrency Level:      3

Complete requests:      3

Failed requests:        2

Time taken for tests:   120.262 seconds

Total transferred:      1423542643 bytes

Requests per second:    0.02 [#/sec] (mean)

Time per request:       120262.109 [ms] (mean)

Time per request:       40087.370 [ms] (mean, across all concurrent requests)

Concurrency Level:      4

Complete requests:      4

Failed requests:        3

Time taken for tests:   120.590 seconds

Total transferred:      1422685724 bytes

Requests per second:    0.03 [#/sec] (mean)

Time per request:       120590.011 [ms] (mean)

Time per request:       30147.503 [ms] (mean, across all concurrent requests)

[Tomoya Shimaguchi]

はじめまして。島口です。

`.readFile()` でファイルをオープンすると、メモリをたくさん使いますよね。500MBって、、、

僕はあんまり、わかんないけど、一度のレスポンスで遅れる量って、限られてるんじゃないでしょうか（？誰か教えて）。

レスポンス自体は、ライタブルストリームなので、小出しに`res.write()`

たとえば、ストリームで開いて、少しずつレスポンスを返すようにする。

```javascript

var fs = require('fs');

var http = require('http');

http.createServer(function (req, res) {

    res.writeHead(200, {'Content-Type': 'image/jpeg' } );

    fs.createReadStream("/home/mongo/testdata500mb")

       .pipe(res);

}).listen(1337);

```
でも、これだと、リクエストが来るたびにファイルをオープンするので、沢山のリクエストを処理しきれないので、

インメモリにキャッシュしたほうがいいですよね。isaacさんのasync-cacheとか便利ですよね（Expressとか使わない場合）。

https://github.com/isaacs/async-cache

[アウゼン]

こんにちは、島口さん
回答ありがとうございます。

500MBは極端な例なのですがおっしゃる通り、リソースの観点で問題があるというのは判ります。

(ちなみにテスト環境は物理メモリ16GBのマシンで、Gangliaで監視してたのですが並行度4のテスト中は2GBくらいメモリ消費していました。)

インメモリにキャッシュして、ファイルの読み込みを減らして、メモリの消費も押さえてしまえばnodeでも

大きなファイルをレスポンスするシステムを組めるのでしょうか。

そもそもnodeで大きなレスポンスを返すのには不向きという前提が間違いなのでしょうか？

[Akitoshi Manabe]

眞鍋です

>> 一度のレスポンスで遅れる量って、限られてるんじゃないでしょうか
その辺は、プロトコル側で解決してくれるかも。(chunked形式によるレスポンスが定義されてたような)


>> メモリの消費も押さえてしまえばnodeでも大きなファイルをレスポンスするシステムを組めるのでしょうか。
大きなファイルのレスポンスは試したことがないので、ご意見させて頂くのも恐縮なのですが、
結論は、「組める」です。ただし、パフォーマンスについては不明。


https://github.com/rabc/node-downloader のようなファイルダウンロード用のモジュールもありますし、
他に node.js で streaming サーバーを作ろうという試みをされ、モジュール公開する方もいるかもしれません。
node streaming videoとか、node streaming audio といったキーワードを当たってみてはいかがでしょう。


>> そもそも「nodeで大きなレスポンスを返すのには不向き」という前提が間違いなのでしょうか？
「まだまだ考察の余地あり」ですよね。
よく耳にするそうですが、Node.js 0.4 系からバリバリ使いこなしてる方々の結論であれば、私もその根拠を聞いてみたいと感じます。

逆に、軽い気持ちで組み上げたコードのパフォーマンスから出た否定意見かもしれないので、否定意見を下したコードを見せて貰って判断してもよいかも。

Node.js ってJavaScriptベースの開発になるので、気軽に組んだコードが思ったようなパフォーマンスを得られないと、それこそ、軽～く敬遠されます。

正直、まだまだ手探りでやっていく部分は大きい。
ただ、大きなファイルを大勢に…となると、サーバーもそれなりのハードウェアを求められるかも。


2012年11月26日 17:07 アウゼン <ovj...@gmail.com>:

> --
>
>
>

[Shigeki Ohtsu]

大津です。

(2012/11/26 16:21), アウゼン wrote:
> こんにちは、アウゼンです
>
> 初歩的な質問で、恐縮ですが
> 「大きなファイルをレスポンスするようなものは、node.jsに向かない」とい
> う話をよく耳にするのですが
> どうして向かないのでしょうか？

ネットワークI/Oに比べてファイルI/Oの方がボトルネックになりやすいからだと
思います。
現状ファイルI/Oで同時利用できるスレッド数は４に制限されていますが、将来
的にはこの制限がなくなる予定です。
それでもシングルCPUでは性能向上に限界があるので、クラスター化などの対応
が必要になる可能性があります。
他にも単純にWebで一度に大容量データを扱うと様々なリソースのボトルネック
が発生する可能性があるので、一般的には向かないと言われているで はないか
と思います。

>
> 下記のような500MBのファイルをレスポンスするソース(極端な例)で試してみ
> ましたが、fs.readFileも responseもブロックする訳でもなく

> どういうことなのか疑問に思っています。
>
> var fs = require('fs');
> var http = require('http');
> http.createServer(function (req, res) {
> fs.readFile('/home/mongo/testdata500mb',function(err,data){
> console.log('responce start!!');
> res.writeHead(200, {'Content-Type': 'image/jpeg' } );
> res.end( data, 'binary' );
> console.log('responce end!!');
> });
> }).listen(1337);
>
> 実際のところソースを動かして確認してみるとうまく動作しないという状況で
> した。
> Apache benchで並行度(Concurrency Level)を1から4にあげていくと、3移行で
> リクエストが失敗してしまっています。
> 結果からはレスポンスが欠落しているように見えるのですが、これが向かない
> 理由につながるのでしょうか？

上の例だとリクエスト毎に data バッファにファイル全部(500MB)を読み込み、
完了したらレスポンスオブジェクトに書き込むということをしているので、簡単
にファイルIOやメモリの ボトルネックが発生しているのでしょう。まずは 、
fs.createReadStream(file).pipe(res);
といった stream の利用を検討すべきです。

ただこれだと64KB毎にデータを読み込みながら全力で書き込んでいるので容易に
イベントループが止まってしまいます。
（ダウンロード中は新規接続を受け付けない状態になってます。）

そこで、ダウンロード速度は落ちてしまいますが、イベントループを止めないよ
ううまく process.nextTick で分散させた例を
https://gist.github.com/4148268
に載せました。

手元で確認したら １Ｇのバイナリーファイルに対して ab で同時100接続でベン
チしても問題なく動作しています。
こういったことの考慮が必要なので、一般的に大容量ファイルの利用に向かない
と言われているのではないかと思います。

[アウゼン]

眞鍋さん

書き込みありがとうございます。

2012年11月26日月曜日 17時45分04秒 UTC+9 aki_mana:

眞鍋です

>> 一度のレスポンスで遅れる量って、限られてるんじゃないでしょうか
その辺は、プロトコル側で解決してくれるかも。(chunked形式によるレスポンスが定義されてたような)


>> メモリの消費も押さえてしまえばnodeでも大きなファイルをレスポンスするシステムを組めるのでしょうか。
大きなファイルのレスポンスは試したことがないので、ご意見させて頂くのも恐縮なのですが、
結論は、「組める」です。ただし、パフォーマンスについては不明。


https://github.com/rabc/node-downloader のようなファイルダウンロード用のモジュールもありますし、
他に node.js で streaming サーバーを作ろうという試みをされ、モジュール公開する方もいるかもしれません。
node streaming videoとか、node streaming audio といったキーワードを当たってみてはいかがでしょう。

情報ありがとうございます。

node-downloader どんなものか確認してみます。

 

>> そもそも「nodeで大きなレスポンスを返すのには不向き」という前提が間違いなのでしょうか？
「まだまだ考察の余地あり」ですよね。
よく耳にするそうですが、Node.js 0.4 系からバリバリ使いこなしてる方々の結論であれば、私もその根拠を聞いてみたいと感じます。
逆に、軽い気持ちで組み上げたコードのパフォーマンスから出た否定意見かもしれないので、否定意見を下したコードを見せて貰って判断してもよいかも。
Node.js ってJavaScriptベースの開発になるので、気軽に組んだコードが思ったようなパフォーマンスを得られないと、それこそ、軽〜く敬遠されます。

正直、まだまだ手探りでやっていく部分は大きい。
ただ、大きなファイルを大勢に…となると、サーバーもそれなりのハードウェアを求められるかも。

お聞きしたら 

適切に実装すれば問題ない、nodeにはもっと他にがんばって欲しい処理があったのでnginxに任せた

ということでした。大きなレスポンスを返すのは不向きというのは、言葉足らずでしたと回答をいただき

ました。

[アウゼン]

大津さん

書き込みありがとうございます。

> 初歩的な質問で、恐縮ですが
> 「大きなファイルをレスポンスするようなものは、node.jsに向かない」とい
> う話をよく耳にするのですが
> どうして向かないのでしょうか？

ネットワークI/Oに比べてファイルI/Oの方がボトルネックになりやすいからだと
思います。
現状ファイルI/Oで同時利用できるスレッド数は４に制限されていますが、将来
的にはこの制限がなくなる予定です。
それでもシングルCPUでは性能向上に限界があるので、クラスター化などの対応
が必要になる可能性があります。
他にも単純にWebで一度に大容量データを扱うと様々なリソースのボトルネック
が発生する可能性があるので、一般的には向かないと言われているで はないか
と思います。

そのような制限があるのですね。納得です。

表面から見ていると判らないですね、もう少し内部的にどのように動作しているのかとか

理解できればいいのですが。

そこで、ダウンロード速度は落ちてしまいますが、イベントループを止めないよ
ううまく process.nextTick で分散させた例を
https://gist.github.com/4148268
に載せました。

手元で確認したら １Ｇのバイナリーファイルに対して ab で同時100接続でベン
チしても問題なく動作しています。
こういったことの考慮が必要なので、一般的に大容量ファイルの利用に向かない
と言われているのではないかと思います。

ありがとうございます、試してみます。

話は違いますが、サーバサイドJavaScript Node.js入門いい本ですね。立ち読み

して、Amazonでポチリました。

[Shigeki Ohtsu]

大津です。

# すみません、なんだ書籍のステマかと嫌がる方もいらっしゃるかと思いますが
ご了承ください。

(2012/11/27 8:58), アウゼン wrote:
>
> 表面から見ていると判らないですね、もう少し内部的にどのように動作してい
> るのかとか
> 理解できればいいのですが。

この部分は簡単ですが「 19.2.4 libeio 」で説明されていますのでご参考にし
て下さい。
なお、学園祭のセッションでも話をさせていただきましたが、 libeio/libev は
次期安定版の node-v0.10 では削除され、新しいlibuv の独自実装に置き換わる
予定です。
既に current の master では置き換わっていますが、性能違いや挙動の変化な
どは外からは全くわからないぐらいです。

>
> そこで、ダウンロード 速度は落ちてしまいますが、イベントループを止
> めないよ
> ううまく process.nextTick で分散させた例を
> https://gist.github.com/4148268 <https://gist.github.com/4148268>

> に載せました。
>
> 手元で確認したら １Ｇのバイナリーファイルに対して ab で同時100接続
> でベン
> チしても問題なく動作しています。
> こういったことの考慮が必要なので、一般的に大容量ファイルの利用に向
> かない
> と言われているのではないかと思います。
>
>
> ありがとうございます、試してみます。

今回の drainイベント、 pause(),、resume() の使い方については、「 9.6
drainイベントを利用したデータ送信制御」 のサンプルコードの応用になります。
しかしこれも学園祭で isaacs が基調講演で話をしていたよう node-v0.10 の
stream2 では違った形の実装になります。
(dataイベント、pause()/resume() が無くなり read(),readable イベントを使
うことになりそうです。）
ただし多少の性能劣化があるものの既存の stream1 APIとの互換性を残すので以
前のコードもそのまま使えるとのことです。
現在ブランチで開発中で個人的にはまだ試していないです。

> 話は違いますが、サーバサイドJavaScript Node.js入門いい本ですね。立ち読み
> して、Amazonでポチリました。

ありがとうございます。別途この本をテキストにした勉強会も開催していますの
で、よろしければご参加ください。
近日中に 2nd シーズンの開催する予定です。

[Kazuyuki Honda]

本多@hakobera です。

大津さんが回答されている内容でアウゼンさんの求めているものは出尽くしていると思いますが、

一応、補足的な意見を書いておきます。

「大きなファイルをレスポンスするようなものは、node.jsに向かない」ではなくて、

「大きなファイルをレスポンスするようなものは、アプリケーションサーバには向かない」。

この辺は、"PHP 大容量ファイル", "Rails 大容量ファイル" とかで検索してもらうとわかりますが、

「大容量ファイルのダウンロードでパフォーマンスがでない」というのは Web系言語の共通の悩みです。

現状、Node.jsなどのアプリケーションがファイルダウンロードを実装するのは、主に以下の2パターンが考えられます。

1. データベースのデータをCSV出力する場合など、データを動的に作成してダウンロードする場合

2. 認証されたユーザにのみ指定の静的ファイルをダウンロードさせる場合

1番のケースは、大津さんの提示された方法（+ Streamのバッファサイズの調整やcluster化）で対応します。

2番のケースの場合なら、別のアプローチがあって、

Reverse Proxy に Nginx がいる前提になりますが、認証のみを Node.js のアプリで実装して、

あとは X-Accel-Redirect ヘッダを付与して、レスポンスを返してあげれば良いです。

var http = require('http');

var server = http.createServer(function (req, res) {

  // なんらかの認証処理でOKだったら

  res.writeHead(200, {

    'X-Accel-Redirect': 'ダウンロードさせたいファイルのフルパス'

    // Content-Type や Content-Disposition, Content-Length はお好みで

  });

  res.end();

});

server.listen(3000);

2012年11月27日 10:00 Shigeki Ohtsu <oh...@iij.ad.jp>:

--

[Kazuyuki Honda]

本多@hakobera です。

> アウゼンさん

悩ましいのは2のケースで、さばききれるならnodeだけでも良いと考えており、この質問の発端になっています。

この辺は同感ですね。わざわざ nginx 立てるのも面倒なのはわかります。

> 最終的にやりたいことは

> 2.のケースに該当する、静的な画像ファイルを認可させてダウンロードさせる

タイトルが「大容量ファイル」だったので、てっきり動画か、巨大ログファイル辺りだと思っていのですが、画像ファイルなんですね。画像ファイルなら大きくても10MB程度だと思うので、Node.js の静的ファイルモジュールで捌けると思います。

Node.jsの静的ファイルモジュールといえば実績と人気の node-static (https://npmjs.org/package/node-static) ですが、

最近出てきた、st (https://npmjs.org/package/st) や

Lactate (https://npmjs.org/package/lactate) も良いと思います。

Lactate は他モジュールとの比較もサイトに載ってますので、色々と特徴が見えて面白いです。

http://weltschmerz.github.com/Lactate/#comparison

また、大容量ファイルではないですが、

Node.js の静的モジュールと Nginx のパフォーマン比較をブログに書いたことがあるので参考までに貼っておきます。

「Node.jsは静的コンテンツには向いていない」のか？

http://hakobera.hatenablog.com/entry/2012/10/22/231534