web-dev-qa-db-ja.com

SpringBootでのTomcatの接続タイムアウトの増加

応答が処理されるまで要求がタイムアウトしないように、タイムアウトを増やすにはどうすればよいですか？

Spring BootのTomcat設定：

_server.Tomcat.max-connections=2000
server.Tomcat.max-threads=200
server.connection-timeout=1200000
_

1秒あたりのリクエスト数は15秒間でconstantUsersPerSec(20) during (15)から300に引き上げられ、すべてのリクエストはgatling（blue）から下のプロットに示されているように処理されました。

_scn.inject(
      constantUsersPerSec(20) during (15), 
    )
_

これは、_max-connections = 2000_ワーカースレッドを使用して300のリクエストを処理した_200_によるものです。

コントローラはSpringMVCで記述されており、非同期要求処理を行うDeferredResultを返すため、応答が処理されると応答を再開します。

Requests Per Sec

しかし、_server.connection-timeout_が高い数値に設定されていても_1200000_終わりに向かって503がたくさんあります（赤）

_> status.find.in(200,304,201,202,203,204,205,206,207,208,209), b     78 (100.0%)
ut actually found 503
_

Response Per Sec

Gatling.confは、タイムアウトを増やすようにも設定されています。

_   timeOut {
      simulation = 8640000 # Absolute timeout, in seconds, of a simulation
    }
    ahc {
      #keepAlive = true                                # Allow pooling HTTP connections (keep-alive header automatically added)
      connectTimeout = 600000                          # Timeout when establishing a connection
      handshakeTimeout = 600000                        # Timeout when performing TLS hashshake
      pooledConnectionIdleTimeout = 600000             # Timeout when a connection stays unused in the pool
      readTimeout = 600000                             # Timeout when a used connection stays idle
      #maxRetry = 2                                    # Number of times that a request should be tried again
      requestTimeout = 600000           
_
javaspringspring-boottomcatgatling
5
fortm

Rcordoval-からのコメントによると

このプロパティを確認してください：spring.mvc.async.request-timeout =＃非同期リクエスト処理がタイムアウトするまでの時間

この設定は、残りのガトリング構成に役立ちます

spring.mvc.async.request-timeout=1200000

ただし、根本的な原因は、要求が大量に来ると、すべてのワーカースレッド（200）が開いている接続のアップロード（2000）で占有されることです（コントローラーはMultipartFileを引数として取り、DeferredResultを返します）

リクエストサーブロジックが速く、ビジネスロジックが遅い場合（forkjoin.commonPoolで実行）にDeferredResultが光ると思います。 MultiPartFileのアップロード（ブロッキングと低速）などには完全には適合しないため、ファイルサイズが大きい場合、応答はすぐに再開されません（上記の応答/秒のグラフに示されているように、接続が開いてから数秒後に応答が再開されます） 2000年で労働者はわずか200人です）。ワーカーが増えると、とにかく非同期処理の利点が軽減されます。

この場合、要求処理（アップロードとブロック）は遅く、ビジネスロジックは高速でした。そのため、応答は準備されていましたが、すべてのワーカースレッド（200）が非常に多くの要求を処理するのに忙しく、応答が再開されず、結果としてタイムアウトになります。

おそらく、DeferredResultを使用した非同期処理でrequest serveとresponse resumeに別々のプールがある場合がありますか？

0
fortm