Dropwizard/Jetty中程度から軽量の負荷でhttpステータス202を返すREST呼び出し

Question

dropwizard 0.7.1.3で構築された休憩サービスで問題が発生しました.Jetty 0.9.7.1.v20131107が埋め込まれていると思います。

このサービスには、バックグラウンドタスクの送信に使用されるものと、ジョブのステータスを確認するものと、最後に完了したときにジョブの結果を取得するものがあります。これらのエンドポイントのどれも明示的に返信していません202.

私は現在、ジョブをサブミットするために同時に複数のユーザーをシミュレートするアプリケーションの負荷テストを行っています。結果を検索します。 30人以上のユーザーが約30人のユーザーに対してシミュレーションを実行するには、約3500件のリクエストが数分間でサービスに送信されます。平均レートは約16 /秒です。この間、いくつかのエンドポイントから202 HTTPステータスコードが返されることがあります。ユーザー数を増やすと、202秒の頻度も増加します。

負荷テスト中にアプリケーションをプロファイリングする際、使用可能なCPUとヒープスペースはどちらも合理的な範囲内にとどまっているようです。ガベージコレクションの場合も同じです。また、使用しているスレッドの数は、約1024のサービスに設定されている最大数よりもはるかに少ないです。

私は今、これらの202の原因を突き止めることができないと思います。私はアクセプタスレッド、セレクタスレッドなどの設定をドロップウィザードの設定で増やしてみましたが、問題を緩和するのに役立ちません。

どのような状況でJettyが202を返すのかについては、私はグーグルで試してみましたが、これに関する有用な情報は見つかりませんでした。

このような問題が発生したことがありますか？誰かが私のことを教えてくれますか？問題を緩和するために私が何を変えることができるのでしょうか？

平均的な16回のリクエストが毎秒202回の返品を保証するには十分であると私には分かりません。これを診断するのに役立つ追加情報がある場合は、お知らせください。

Answer 1

最終的に、社内の図書館に実際には非常に特殊なケースで202を返すコードがあることがわかりました。

Answer 2

注：この質問はあまりにも不明であり、私はそれにフラグを立てます。しかし、私のコメントはサイズの要件に合っていません。

あなたはJettyあなたは桟橋QoSまたはDoSフィルタのいくつかの奇妙な設定のためにチェックすることができ責任があることをabsolutely sureしている場合。デフォルトの戻りコードはHTTP 503 Service unavailableですが、戻りコードは構成可能です。

IMO HTTP 202ステータスコードは、アプリケーションからの意図された動作のようです。 IANA状態でHTTPステータスコードの公式レジストリ：

202 AcceptedRFC7231, Section 6.3.3

202レスポンスは意図的に曖昧です。その目的は、 が、サーバへのユーザエージェントの接続が、処理が完了するまで、 まで続くことを要求することなく、サーバがある他のプロセス（おそらく バッチ指向のプロセス）の要求を受け入れることを許可することです。 。この応答で送信された表現 は、要求の現在の状態を記述し、 の要求が実行される見積もりをユーザに提供できる状態モニタを に指し示す（または埋め込む）べきです。

バッチ指向のプロセスとして、たとえば、いくつかのWebサーバーまたはS3のようなオブジェクトストレージへの数GBのファイルのエクスポートを想像することができます。サーバーは要求を受け入れ、プロセスに関係する他のシステムを正常に指示し、タスクが開始されたことを通知します。すぐに結果を提供することはできません。いつ、どこで結果が見つかるかは、アプリケーションによって異なり、ドキュメントで確認する必要があります。