5

モバイル クライアントを扱う場合、HTTP リクエストの送信中に数秒の遅延が発生することはよくあることです。プリフォーク Apache からページまたはサービスを提供している場合、アプリケーション サーバー ロジックが 5 ミリ秒で完了したとしても、子プロセスは 1 つのモバイル クライアントにサービスを提供するために数秒間拘束されます。以下をサポートする HTTP サーバー、バランサー、またはプロキシ サーバーを探しています。

  1. プロキシにリクエストが届きます。プロキシは、ヘッダーと POST/PUT 本文を含む要求の RAM またはディスクへのバッファリングを開始します。プロキシはバックエンド サーバーへの接続を開きません。これはおそらく最も重要な部分です。

  2. プロキシ サーバーは、次の場合に要求のバッファリングを停止します。

    • サイズ制限 (4KB など) に達した、または
    • リクエストはヘッダーとボディを含めて完全に受信されました

  3. 要求 (の一部) がメモリ内にある場合にのみ、バックエンドへの接続が開かれ、要求が中継されます。

  4. バックエンドは応答を返します。ここでも、プロキシ サーバーはすぐにバッファリングを開始します (より寛大なサイズ、たとえば 64KB まで)。

  5. プロキシには十分な大きさのバッファがあるため、バックエンド レスポンスは数ミリ秒でプロキシ サーバーに完全に格納され、バックエンド プロセス/スレッドはより多くのリクエストを自由に処理できます。バックエンド接続はすぐに閉じられます。

  6. プロキシは、リソースを拘束するバックエンドへの接続を持たずに、可能な限り高速または低速でモバイル クライアントに応答を返します。

Squid で 4 ～ 6 を実行できると確信しており、nginx は 1 ～ 3 をサポートしているようです (そして、この点でかなりユニークに見えます)。私の質問は次のとおりです。これらのバッファリング機能と準備が整うまで接続を開かない機能に共感するプロキシサーバーはありますか? たぶん、このバッファリング動作を簡単にするApache config-fuが少しあるのでしょうか? Squid のような恐竜ではなく、無駄のない単一プロセス、非同期、イベントベースの実行モデルをサポートするものはありますか?

（サイダーラント：私はnginxを使用していますが、チャンクされたPOSTボディをサポートしていないため、モバイルクライアントにサービスを提供するのには役に立ちません。はい、安価な50ドルのハンドセットはチャンクされたPOSTが大好きです...ため息）

4

5 に答える 5

4

nginx と Squid (クライアント — Squid — nginx — バックエンド) の両方を使用するのはどうですか? バックエンドからデータを返すとき、Squid はデータを CTE: チャンクから Content-Length が設定された通常のストリームに変換するため、POST も正規化できる可能性があります。

于 2008-09-24T11:36:40.363 に答える
2

Nginxはあなたが望むすべてを行うことができます。探している構成パラメーターは次のとおりです。

http://wiki.codemongers.com/NginxHttpCoreModule#client_body_buffer_size

と

http://wiki.codemongers.com/NginxHttpProxyModule#proxy_buffer_size

于 2008-10-01T08:03:35.330 に答える
2

Telerik の無料ツールであるFiddlerは、探していることの少なくともいくつかを実行します。

具体的には、に移動してRules | Custom Rules...、接続中のすべてのポイントで任意の Javascript コードを追加できます。必要なもののいくつかは、sleep()呼び出しでシミュレートできます。

ただし、この方法で必要な細かいバッファリング制御が得られるかどうかはわかりません。それでも、何もないよりはましかもしれません。

于 2008-09-18T23:39:39.217 に答える
1

Squid 2.7 は、パッチで 1 ～ 3 をサポートできます。

私はこれをテストし、ディスクではなくメモリにのみバッファリングするという条件で、うまく機能することを発見しました（もちろん、スワップしない限り、そしてこれを望まない場合）、ボックスで実行する必要がありますワークロードに合わせて適切にプロビジョニングされます。

チャンクされた POST は、ほとんどのサーバーと仲介者にとって問題です。本当にサポートが必要ですか? 通常、クライアントは 411 を受け取ったときにリクエストを再試行する必要があります。

于 2010-04-15T03:08:06.297 に答える
0

残念ながら、私はこれに対する既成の解決策を知りません。最悪のシナリオでは、たとえば Java NIO を使用して自分で開発することを検討してください。1 週間以上かかることはありません。

于 2008-09-19T09:37:18.407 に答える