1

最後の

さらにテストを行った結果、G-WAN の新しいバージョンでは、すべてが期待どおりに機能することが明らかになりました。

オリジナル 私は大きなファイルを扱っており、G-WAN は私のユースケースに最適なようですが、コンテンツをクライアントにストリーミングすることに頭を悩ませているようには見えません。

メモリが非常に速く消費されるため、バッファリングされた応答を避けたいと思います。

4

3 に答える 3

2

ソースコード公開中

ありがとう。取得した値は明らかに間違っています。これは、CLIENT_SOCKET 列挙型が定義されている gwan.h ファイルの不一致に起因する可能性があります。実行可能ファイルと同期するファイルについては、次のリリースを待ちます。

以下で説明するように、ローカル ファイルは G-WAN によってストリーミングされて提供され、リモート ファイルは G-WAN のリバース プロキシを使用してより適切に提供されるため、ストリーミング ファイル (ローカル ファイルまたはリモート ファイルのいずれか) について CLIENT_SOCKET を処理する必要はありません。

ディスクへのコピーと gwan からの提供は非効率的であり、メモリ内のファイルのバッファリングも非効率的です

Nginx や他の多くの G-WAN と同様に、既に使用されているため、 「大きなファイルをクライアントにストリーミングする」sendfile()ために何もする必要はありません。

sendfile() を調べましたが、gwan がクライアント ソケットを格納する場所が見つかりませんでした。CLIENT_SOCKET を使用しようとしましたが、機能しませんでした

CLIENT_SOCKETがクライアント ソケットを返さない唯一の方法は、実行可能ファイルgwan.hのバージョンと一致しないヘッダーを使用することです。gwan

G-WAN を使用することで、 connection handlerG-WAN のデフォルトの動作をバイパスできます (それがあなたが試したことだと思います)... しかし、G-WAN はすでに達成しようとしていることを行っているため、これは不要です (上記で説明したように)。

これを念頭に置いて、G-WAN と に関するいくつかのポイントを次に示しますsendfile()。

  • G-WAN の古いリリースが誤って無効になりsendfile()ました - 使用しないでください。より新しいリリースを使用していることを確認してください。

  • 4 月のパブリック リリースでは、接続を閉じる際に注意が必要でした (キープアライブされていない接続を遅くする)sendfile()ため、特定のサイズを超えるファイルに対してのみ使用していました。

  • 最近の開発リリースではsendfile()、すべての静的ファイルに使用されています (デフォルトでは、あまりにも多くのユーザーを混乱させるため、グローバル、接続ごと、または特定のリソースに対して明示的に復元できるキャッシュを無効にしました)。

その結果、大きなファイルのテスト ロードの場合、G-WAN は、テストした他のすべてのサーバーよりも高速になりました。

また、sendfile() で提供される大きなファイルであっても、比類のないレベル (Nginx のメモリ消費量のごく一部) に達するように、メモリ消費量を大幅に作り直しました。

G-WAN は起動時on a 6-Core Xeonに 2.2 MB の RAM を使用します (サーブレットやハンドラーなどのコンパイルおよびロードされたスクリプトを除く)。

> Server 'gwan' process topology:
---------------------------------------------
  6] pid:4843 Thread
  5] pid:4842 Thread
  4] pid:4841 Thread
  3] pid:4840 Thread
  2] pid:4839 Thread
  1] pid:4838 Thread
  0] pid:4714 Process RAM: 2.19 MB
---------------------------------------------
Total 'gwan' server footprint: 2.19 MB

対照的に、Nginxworker_connections 4096;は起動時に 15.39 MB を消費します。

> Server 'nginx' process topology:
---------------------------------------------
  6] pid:4703 Process RAM: 2.44 MB
  5] pid:4702 Process RAM: 2.44 MB
  4] pid:4701 Process RAM: 2.44 MB
  3] pid:4700 Process RAM: 2.44 MB
  2] pid:4699 Process RAM: 2.44 MB
  1] pid:4698 Process RAM: 2.44 MB
  0] pid:4697 Process RAM: 0.77 MB
---------------------------------------------
Total 'nginx' server footprint: 15.39 MB

また、Nginx とは異なり、G-WAN は事前にメモリを予約しなくても (ちなみに構成も必要ありません)、100万を超える同時接続を処理できます。

Nginx を構成すると、次のようにworker_connections 1000000;なります。

> Server 'nginx' process topology:
---------------------------------------------
  6] pid:4568 Process RAM: 374.71 MB
  5] pid:4567 Process RAM: 374.71 MB
  4] pid:4566 Process RAM: 374.71 MB
  3] pid:4565 Process RAM: 374.71 MB
  2] pid:4564 Process RAM: 374.71 MB
  1] pid:4563 Process RAM: 374.71 MB
  0] pid:4562 Process RAM: 0.77 MB
---------------------------------------------
Total 'nginx' server footprint: 2249.05 MB

Nginx は、接続を受信する前でも 2.2 GB の RAM を消費しています!

同じシナリオで、G-WAN に必要な RAM は 2.2 MB だけです (1024 分の 1)。

また、G-WAN は、大きなファイルの場合、Nginx よりも高速になりました。

リモート ソースから大きなファイルをストリーミングしたい

sendfile()「リモートソースから大きなファイルをストリーミングしたい」と述べているように、探しているものではないかもしれません。

ここで、私があなたの質問を正しく理解していれば、G-WAN をリバース プロキシとして使用してリモート リポジトリから大きなファイルを中継したいと考えていますが、これは (ローカル ファイルを提供するのとは対照的に) まったく別のゲームです。

最新の G-WAN 開発リリースには、G-WAN でパーソナライズできる汎用 TCP リバース プロキシ機能がありますconnection handler。

しかし、あなたの場合、バックエンドサーバーの応答をフィルタリングして変更できるようにする代わりに、ブラインドリレー（トラフィックの書き換えなし）ができるだけ速くなるだけで済みます.

Griffin が言及したsplice()syscall は (ゼロコピー) 方法であり、G-WAN の (効率的なイベントベースおよびマルチスレッド) アーキテクチャは、特に RAM 使用量が少ない場合に驚異的です。

G-WAN は将来のリリースでこれを行うことができます (これはトラフィックを変更するよりも簡単です) が、Web/クラウド開発者がアプリケーションを作成できるようにするという G-WAN の主なターゲットとは対照的に、これはかなり垂直的なアプリケーションです。

とにかく、このレベルの効率が必要な場合、G-WAN は新しいレベルのパフォーマンスに到達するのに役立ちます. G-WANのウェブサイトからお問い合わせください。

于 2013-10-24T07:43:26.867 に答える
0

コメットではなく、おそらく http ストリーミングを意味していると思います。この場合、gwan で提供される flv.c 接続ハンドラの例があります。sendfile()また、必要に応じて、ファイルのゼロコピー転送にc を使用するか、 splice()syscall を使用できます。

于 2013-10-23T22:11:31.483 に答える