8

http://www.erlang.org/doc/man/gen_tcp.html#accept-1から:

accept 呼び出しは、ソケット所有者プロセスから発行する必要がないことに注意してください。バージョン 5.5.3 以降のエミュレーターを使用すると、複数の同時受け入れ呼び出しを異なるプロセスから発行できます。これにより、着信接続を処理する受け入れプロセスのプールが可能になります。

(Q1) Erlang でUnicornスタイルの負荷分散ができるということですか?

(Q2)もしそうなら、この機能を利用している既存のサーバーやライブラリはありますか?

(Q3) Unicorn は、リクエスト処理が速いことを前提に動作します。同じ仮定の下で、Erlang でアクセプターとワーカーを組み合わせることでパフォーマンスを向上させることは可能ですか?

Unicorn に慣れていない方のために説明すると、Unicorn は従来の UNIX プレフォーク Web サーバーです。ワーカー プロセス間の負荷分散は、OS カーネルによって行われます。すべてのワーカーは共通のリスナー ソケットのセットを共有し、ノンブロッキングの accept() を実行します。カーネルは、ソケットを与えるワーカー プロセスを決定し、accept() するものがない場合、ワーカーはスリープします。単一のリスナーソケットの場合、ワーカープロセスがaccept（）をブロックし、OSカーネルが「レース」の結果を決定する場合も同じだと思います。

4

1 に答える 1

4

この質問は、Erlang Questions メーリング リストにも投稿しました。Daniel Goertzenが指摘したように、Erlang には、 ranchやswarmなどのアクセプター プール ライブラリがあります。

  • 牧場は、多くのプロセスで「受け入れ」のみを行い、ソケットをワーカープロセスに渡すという点で、Unicorn とは異なる動作をします。

  • swarmの仕組みは、acceptor と worker が組み合わされているという意味で Unicorn と同じです。(指摘してくれたLoïc Hoguinに感謝します) しかし、Swarm は受け入れたソケットの処理と並行して新しいソケットを受け入れることができるのに対し、Unicorn は受け入れたソケットが処理された後にのみ受け入れるため、これらは少し異なります。

Unicorn は高速なリクエストを必要とするのに対し、高速なリクエストと低速なリクエストの両方に理想的であるため、swarm スタイルを好みます。

Unicorn は、低速のクライアントに効率的にサービスを提供しようとする代わりに、バッファリング リバース プロキシに依存して低速のクライアントを効率的に処理します。

unicorn はすべてのアプリケーションに適しているわけではありません。unicorn は、CPU/メモリ/ディスクを集中的に使用し、外部リソース (データベース サーバーや外部 API など) の待機にほとんど時間を費やさないアプリケーション向けに最適化されています。

unicorn は、HTTP 接続がアイドル状態で長時間を費やす Comet/reverse-HTTP/push アプリケーションでは非常に非効率的です。

于 2013-01-03T04:06:37.080 に答える