wcf - Web サービス タイムアウトのベスト プラクティス

Question

WS タイムアウトの上限設計制限を定義する記事/本はありますか? サーバーでタイムアウトしますか、それともクライアント固有のタイムアウトを推奨しますか?

「60 秒以上かかる可能性がある WS を設計しない、非同期トークン パターンを使用する」などの一般的なベスト プラクティスはありますか?

あなたが何をしているのか、またはあなたの意見も知りたいです。

Answer 1

30秒以上のタイムアウトについてのこのようなものはばかげたアドバイスです、IMO。タイムアウトは約3秒である必要があります。はい。三。2の後と4の前の数。SOAに基づいてアプリケーションを構築している場合は、間違いなく3秒以内です。

考えてみてください...アプリのユーザーは、合計応答時間が約5秒以下（できれば約3秒）になると予想しています。各個別のサービスコールが戻るのに数ミリ秒*以上かかる場合は、問題が発生します。1つのサービスが戻るのを30秒以上待つのは永遠です。ユーザーはそんなに長く待つことはありません。さらに、1秒未満の範囲で戻ることになっていることがわかっている場合、エラー状態を通知するためにさらに30秒以上待機するポイントは何ですか。28秒前には機能しなかった場所で魔法のように機能することはありません。アプリケーションの平均応​​答時間が1秒未満から30秒を超えるまで大きく変動する場合は、何かが正しく設計されていません。キャッシングか何かについて考えるかもしれません。

Answer 2

この質問と、それに対する回答でリンクされている質問が役立つ場合があります。 許容できないWebアプリケーションの応答時間に関する業界標準はありますか?

あなたの質問には多少接していますが（時間間隔はありません、申し訳ありません）、あなたの仕事に役立つと思います：タイムアウトへの一般的なアプローチは、「バックオフ」タイマーとのバランスを取ることです。
それは次のようなものです: サービスが初めてタイムアウトになった場合、心配する必要はありません。サービスが 2 回連続でタイムアウトになった場合、わざわざ N 秒間呼び出す必要はありません。サービスが 3 回連続でタイムアウトになった場合は、N+1 秒間呼び出さないでください。次に、最大制限 M に達するまで、N+2、N+3、N+5、N+8 などを繰り返します。

有効な応答を取得すると、タイムアウト カウンタはリセットされます。

ここではフィボナッチ数列を使用して「バックオフ」期間を増やしていますが、もちろん、他の適切な関数を使用することもできます。ポイントは、試みているサービスがタイミングを維持している場合、それを「信じる」ことです。ますます小さくなるため、そこにたどり着くために費やすリソースが少なくなり、ドアをノックする頻度が少なくなります。これは相手側のサービスを助けるかもしれませんが、それは単純に過負荷になる可能性があり、再要求は事態を悪化させるだけであり、応答する可能性が低いサービスを待つ必要がないため、応答時間が長くなります.

Answer 3

通常、そのWebサービスの予想される応答時間（インターフェース仕様に記載されている）を取得し、それに30秒を追加します。

次に、UAT中にログを監視して、パターン（たとえば、特定のDB呼び出しに時間がかかる）があるかどうかを確認し、必要に応じて変更します。

Answer 4

Web サービスを介して転送しているデータの量を取り、プロセスにかかる時間を確認します。

その数に 60 秒を追加してテストします。

良好な接続でタイムアウトになる場合は、さらに 30 秒追加します。

すすぎ、繰り返します。