単純なasp.netWebコントロールをまとめています。これは、ajaxフォームの投稿の結果としてMSQLデータベースにレコードを挿入します。
このコントロールを含むページは、短い時間内に何千ものヒットを受け取る可能性があり、データベース接続を開き、レコードを挿入してから、リクエストごとに接続を閉じるというパフォーマンスの問題が心配です。
私が思いついた解決策は、WebコントロールにメッセージをMSMQキューに配置させ、サーバー上のWindowsサービスに定期的にキューを読み取らせてバッチ挿入を実行させることです。
Webサーバーとデータベースサーバーが同じマシンで実行されていることを考えると、それは賢明なアーキテクチャのように聞こえますか？必要ですか？
私がデータベースで読んだことから、MSMQを使用する利点のほとんどは、パフォーマンスではなく回復力に関係しているため、間違ったツリーを吠えている可能性があります。
アドバイスをいただければ幸いです
どうもありがとう
ピート
このようにリクエストをオフラインで処理することは、大量のリクエストを処理する場合の一般的なパターンです。
これを行う必要があるか、または行うことができるかは、多くの要因に基づいています。
主な要因は、呼び出し元が要求に対する応答を同期的に確認する必要があるかどうかです。
私が言いたいのは、データベースが呼び出し応答の一部としてデータを正常にコミットしたかどうかを、呼び出し元が即座に絶対確実に知る必要があるということですか? その場合、リクエスト処理をオフラインにすることは実際には選択肢ではありません。
ただし、要求がオフラインで処理されることを示す応答を発信者に送信できる場合 (および必要な応答もオフラインで送信される場合) は、キューを使用することでアーキテクチャ全体に確実にメリットがあります。
最初に恩恵を受けるのは、フロントエンドの可用性の問題です。
短期間に数千のリクエストを処理していて、各リクエストがスレッドによって処理され、スレッドがデータベースにデータを挿入すると、着信リクエストを処理するために使用できるディスパッチャ スレッドが存在しないという問題が発生する可能性が非常に高くなります。
ただし、IIS が実行するバックエンド作業の量を減らすことによって (ローカル キューへの書き込みは、データベース呼び出しに比べて非常に安価です)、可用性に基づく障害の可能性も減らします。
次に、キューを使用すると、バックエンド処理のスループットを制御できるため、バックエンド トラフィックを調整する手段が得られます。
たとえば、リクエストをデキューしてデータベースに処理するシングルスレッドのキュー リーダー プロセスを作成できます。キューにメッセージが蓄積されていることがわかった場合は、キュー リーダー サービスのインスタンスをさらにホストすることで、キュー リーダー サービスをスケールアウトできます。
これが意味することは、一度にデータベースにアクセスするスレッドの数をより細かく制御できるため、データベースの競合の問題が発生する可能性が減少するということです。
そのため、キューイングを使用することで、適切に作成されたアプリケーションの特徴である障害が少なくなり、管理オーバーヘッドが軽減されます。これは特に、Web サーバーでデータベースをホストすることを検討している場合に役立ちます。
また、 CQRSと呼ばれるアーキテクチャ パターンを読んでおく必要があります。その中心的な原則の 1 つは、データベースへの書き込みをオフラインで行うことです。
非同期アーキテクチャには（Hughによって特定されたように）多くの利点がありますが、それに関連するコストと複雑さは間違いなく大きくなります。これは慎重にバランスを取る必要があります.2つのコンポーネント（WebアプリとDB）から、4つのコンポーネント（Webアプリ、DB、バッチサービス、MSMQ）を開発、保守、監視する必要があります。WebサーバーとDBサーバーは同じマシンであり、パフォーマンス要件を考えると奇妙だとおっしゃいました。明日は、Webアプリ、バッチサービスをホストする必要があるかもしれません。また、DBは3台の別々のマシンです。現在、MSMQにはネットワークも含まれています。うまくいかないことがもう1つあります。マルチスレッドバッチプロセッサも簡単ではありません。各メッセージを（少なくとも特定のエンティティに対して）生成された順序で処理する必要がある場合、ロジックが複雑になる可能性があります。
可能であれば、両方のソリューションを測定して決定します。