WCF を使用して、値を計算し、クライアントに応答を返す RESTful サービスを作成しました。
大量のトラフィックが予想されるため、キューを手動で実装する必要があるのか、それともすべてのクライアント リクエストを処理する必要がないのかがわかりません。
実際には、データベースに保存する必要があるクライアントから測定値を受信しています。各クライアントは 200 ミリ秒ごとに測定値を送信するため、複数のクライアントがある場合、多くの要求が発生する可能性があります。
そして、受信したデータに対して実行される他の操作。たとえば、クライアントは「最後の 200 回の測定値の平均を教えてください」という命令を送信できるため、この値を計算するのに時間がかかり、その間に別のクライアントから同じ要求が来る可能性があります。
WCF を使用して信頼性の高いサービスを作成する方法について、誰かアドバイスをいただければ幸いです。
ありがとう！
MsmqBinding を使用して、eedsi9n によって実装されたメソッドを利用できます。しかし、この投稿から私が収集していることは、pub/sub タイプのアーキテクチャに沿ったものを探しているということです。
これは、サブスクライバーがイベントをサブスクライブできるようにする WSDualHttpBinding を使用して実装できます。アクションが完了すると、パブリッシャーはユーザーに通知します。
したがって、Msmq をバックグラウンドで実行することができます。クライアントは特定のイベントをサブスクライブし、おそらく処理が必要なメッセージを発行します。クライアントはそこに座って動作し (すべて非同期であるため)、パブリッシャーがメッセージの処理を完了すると、イベント (クライアントがサブスクライブしたイベント) を発行して、完了したことを知らせることができます。そうすれば、ポーリング戦略を実装する必要はありません。
これには、あらかじめ用意されたソリューションもあります。NService Bus、Mass Transit、Rhino Bus など。
Web サービスを使用している場合、Transmission Control Protocol (TCP/IP)はある程度キューとして機能します。
TCP は、あるコンピューター上の 1 つのプログラムから別のコンピューター上の別のプログラムへ、バイト ストリームの信頼性の高い順序付けられた配信を提供します。
これにより、クライアントがパケット A、B、次に C を送信した場合、サーバーは A、B、C の順に受信することが保証されます。リクエストと同じ順序でクライアントに返信する必要がある場合は、列。
デフォルトでは、ASP.NET ワーカー スレッドの最大数は CPU コアあたり 12 スレッドに設定されています。したがって、デュアル コア マシンでは、一度に 24 の接続を実行できます。計算にかかる時間と「大量のトラフィック」の意味に応じて、さまざまな戦略を試すことができます。
最も簡単な方法は、serviceTimeouts と serviceThrottling を使用して、処理できるものだけを処理し、処理できないものを拒否することです。
それができない場合は、ハードウェアを増やしてください。それが 2 番目のオプションです。
最後に、サービスを完全に非同期にすることができます。
string PostCalc(...)と の 2 つのメソッドを実装しdouble GetCalc(string id)ます。パラメータを受け取り、それらをキュー (またはデータベース) に詰め込み、すぐに GUID を返します (私はの代わりにPostCalc使用するのが好きです)。クライアントは、返された GUID をクレーム チケットとして使用し、数秒ごとに呼び出すことができます。計算がまだ終了していない場合は、REST に対して 404 を返すことができます。計算は、キューを監視する別のプロセスで実行する必要があります。stringGuidGetCalc(string id)
3 番目のオプションは最も複雑ですが、結果は、着信要求に上限を設定する最初のオプションと同様です。
「何らかの値を計算する」および「大量のトラフィック」が何を意味するかによって異なります。負荷テストを行って、#requests/second がトラフィックとともにどのように変化するかを確認できます。
あなたがRESTfulである場合、ここにWCF固有のものは何もありません平均のGETは、サーバーが計算を終了すると答えが待機するURIを提供します（実際に長い操作である場合）測定値の取得に関して-必要な鮮度を指定しませんでした（つまり、平均のリクエストを受け取ったとき-結果をどれだけ新鮮にする必要がありますか）また、クエリの相対頻度と新しい測定値を指定しませんでしたいずれにせよ、キューを使用できます（およびIMHOは使用する必要があります）パフォーマンスを測定すると、エンドポイントの背後にあることが証明されます。WCF バインディングを変更すると、RESTful のままになる可能性がありますが、REST over HTTP の標準ベースのアプローチのメリットはありません。