2

最近、erlang と Yaws で REST API の作業を開始しました。yaws と私のモジュールが複数のリクエストを処理する方法がわかりません。

すべてのリクエストを収集するAPIモジュールがあります：

appmods = </, api>

そして私のテストモジュール：

-module(api).
out(_Arg) ->
    io:format("my pid  ~p ~n", [self()]),
    loop(200000000),
    [{status, 200}, {header, {"Vary", "Accept"}},
     {content, "application/json", ""}].

この時点で、yaws は api モジュールのインスタンスを 1 つだけ生成し、そこにすべてのリクエストを送信することを理解しています。そのため、一度に処理できるリクエストは 1 つだけです。

APIモジュールのプロセスをさらに生成し、それらの間でリクエストを分散させる方法はありますか?

それとも、API リクエストの種類ごとにさらに多くの appmod を実行する必要がありますか?

それとも、ヨーがどのように機能するかについての私の理解は根本的に間違っていますか?

手伝ってくれてありがとう。

4

1 に答える 1

1

内部的には、Yawsはアクセプタープロセスのプールを保持しています。リクエストはこれらのプロセスで処理されます。Yawsは、appmodごとに新しいプロセスを生成せず、特定のappmodに対するすべての要求をそのプロセスに送信します。むしろ、アクセプターは新しい接続を処理し、その接続で要求を読み込んでディスパッチし、応答を送信します。クライアントが接続を閉じるか、「Connection：close」HTTPヘッダーが存在するか、HTTP 1.0要求（デフォルトでは、各要求/応答の後に接続を閉じる必要があります）が原因で、または接続が閉じられると、クライアントが非アクティブになり、サーバーがクライアントを閉じると、アクセプタープロセスはプールに戻ります。

上記のコメントにリンクされている出力のJPEG画像は、すべてのリクエストを処理する同じpidを示しています。これは、クライアントが接続を開いたままにして、同じ接続で新しいリクエストを送信しているため、同じサーバープロセスがすべてのリクエストを処理している可能性があります。代わりに、 Apache Bench （「ab」とも呼ばれます）のようなクライアントを試してみると、デフォルトでHTTP 1.0になり、リクエストごとに新しい接続が確立されます。リクエストごとに異なるプロセスが処理されます。

ちなみに、appmodについて注意する必要があるのは、などの末尾再帰ループを実行する状態保持プロセスを使用してそれらを実装する場合、gen_serverそのappmodに対するすべての要求は、実際には同じpidに送信されます。ループプロセスのpid。つまり、リクエストは最初に前述のようにYawsアクセプタープロセスで処理されgen_serverますが、appmodが呼び出すと、プロセスにクロスオーバーします。この単一プロセスへのリクエストのシリアル化は、Yawsとは関係ありませんが、appmodの実装方法とは関係ありません。詳細については、これに関する私の公開記事の1つをお読みください。つまり、そのような要求のシリアル化がアプリケーションで受け入れられる場合を除いて、そのようにappmodを記述しないでください。

于 2013-03-16T12:33:23.690 に答える