3

Webサーバーが一部のリクエストをバックエンドサーバーにリダイレクトするアプリを入手しました。バックエンドサーバー（Linux）は複雑な計算とWebサーバーへの応答を行います。Web サーバーとバックエンド サーバー間の tcp ソケット接続管理には、次の 2 つの基本的な戦略があると思います。

  1. 「短い」接続: つまり、リクエストごとに 1 つの接続です。これは、ソケット管理が非常に簡単で、プログラム構造全体が単純化されているようです。acceptの後、リクエストを処理するスレッドを取得し、最後にこのソケットを閉じます。

  2. 「長い」接続: つまり、1 つの tcp 接続に対して、複数の要求が 1 つずつ存在する可能性があります。この戦略は、ソケット リソースをより有効に活用し、パフォーマンスを向上させる可能性があるようです (よくわかりません)。しかし、これは「短い」接続よりも多くの複雑さをもたらすようです。たとえば、ソケット fd がマルチスレッドで使用される可能性があるため、同期が必要になります。さらに、ソケット障害プロセス、メッセージ シーケンスなどがあります。

これら2つの戦略について何か提案はありますか?

更新:、@SargeATM の回答は、バックエンド サービスについて詳しく説明する必要があることを思い出させてくれます。各リクエストは一種のコンテキストフリーです。バックエンド サービスは、1 つのリクエスト メッセージに基づいて計算を実行できます。sthらしい。ステートレス。

4

3 に答える 3

2

この決定に大きな影響を与えると思われるバックエンドのアーキテクチャには触れませんが、ステートレスな「クイック」リクエスト/レスポンス タイプのトラフィックには短い接続を、同期やファイル転送などのステートフル プロトコルには長い接続を好みます。

新しい接続 (ローカル ホストでない場合) を確立するための tcp オーバーヘッドがあることは知っていますが、アプリケーションで最適化する必要があったことは一度もありません。

これは重要なので、アーキテクチャについて少し説明します。私は常にリクエストごとではなく関数ごとにスレッドを使用します。したがって、ソケットでリッスンするスレッドがあります。すべてのアクティブな接続からパケットを読み取る別のスレッドと、バックエンドの計算を実行する別のスレッド、および必要に応じてデータベースに保存する最後のスレッド。これにより、物事がすっきりとシンプルに保たれます。スロー スポットの測定、維持、および後で必要に応じて最適化することが容易です。

于 2012-07-10T04:18:15.247 に答える
0

まあ、あなたは正しいです。

永続的な接続の最大の問題は、アプリがプールから「クリーンな」接続を取得したことを確認することです。別のリクエストからのデータのゴミを残さずに。

その問題に対処する方法はたくさんありますが、最後に、汚染された接続を close() して新しい接続を開く方が、きれいにするよりも優れています...

于 2012-07-12T12:56:18.040 に答える
0

3 番目のオプションはどうですか...接続なし!

ジョブの説明とジョブの結果がどちらも小さい場合は、UDP ソケットを使用することをお勧めします。要求/応答をファイル記述子にバインドする必要がないため、管理するリソースがさらに少なくなり、将来の柔軟性が得られます。より多くのバックエンド サービスがあり、負荷分散を行いたいとします。ビジー状態のサービスは、ジョブ サブミッターの UDP アドレスを使用して、別のサービスにジョブを送信できます。後者は結果を待つだけで、どこでタスクを実行したかは気にしません。

明らかに、失われたパケット、重複したパケット、および順不同のパケットに対処する必要がありますが、報酬として、切断された接続に対処する必要はありません. 要求と応答を 1 つの UDP メッセージに収めることができれば、パケットの順序が乱れてもおそらく大したことではありません。重複はいくつかのジョブ ID で処理でき、パケットが失われます...まあ、それらは単純に再送信できます ;-)

このことを考慮！

于 2012-07-10T19:50:50.697 に答える