ホームページ >Java >&#&チュートリアル >SpringBoot は同時にいくつのリクエストを処理できますか?
SpringBoot のデフォルトの組み込みコンテナが Tomcat であることは誰もが知っています。つまり、プログラムは実際には Tomcat で実行されます。したがって、SpringBoot が処理できるリクエストの数ではなく、Tomcat が処理できるリクエストの数が重要です。
Tomcat のデフォルト構成は spring-configuration-metadata.json
ファイルにあり、対応する構成クラスは org.springframework.boot.autoconfigure.web.ServerProperties
。
#処理されたリクエストの数に関連するパラメータは 4 つあります:
server.tomcat.threads.min-spare: ワーカー スレッドの最小数。デフォルトのサイズは 10 です。このパラメーターは長期ワーカーと同等であり、同時リクエストの数が 10 に達しない場合、これらのスレッドが順番に使用されてリクエストが処理されます。 server.tomcat.threads.max: ワーカー スレッドの最大数。デフォルトのサイズは 200 です。このパラメータは一時ワーカーに相当し、同時リクエスト数が 10 ~ 200 の場合、これらの一時ワーカー スレッドが処理に使用されます。 server.tomcat.max-connections: 接続の最大数、デフォルトのサイズは 8192 です。 Tomcat が処理できるリクエストの最大数を示します。8192 を超えるリクエストは待機キューに入れられます。
server.tomcat.accept-count: 待機キューの長さ。デフォルトのサイズは 100 です。
これらのパラメータ間の関係を説明する例を示します。
Tomcat をレストランに例えると、リクエストは次のようになります。実際にはゲストに相当します。 min-spare はシェフ (正社員)、max はシェフ (正社員と臨時従業員) の総数、max-connections はレストランの座席数、accept-count は入り口にある小さなベンチの数です。 。来客者を優先して店内に座り、その後シェフが仕事を始める 長期勤務者が仕事を終えられる場合は長期勤務者に任せる 長期勤務者が仕事を終えることができない場合は長期勤務者に任せる、派遣社員にやってもらいましょう。写真にはシェフが15人いますが、店内は30席あるので、今20人来たら先に5人が店内で待つことになります。今 35 人が来てレストランに空きがない場合、最初に 5 人が入り口に座るように求められます。 50人来たらホテルの入り口に40席と小さなベンチがあるので10人は帰ることになります。
つまり、SpringBoot が同時に処理できるリクエストの最大数は max-connections accept-count
であり、この数を超えるリクエストは直接破棄されます。
私が知っているのは、この件は詳細に実行する必要があるということだけです。
上記は単なる理論上の結果です。次に、小さな実践的な例を使用して、これが事実であるかどうかを示してみましょう:
SpringBoot プロジェクトを作成し、application.yml パラメーターでこれらを構成します。デフォルトの数値は大きすぎてテストが難しいため、小さい値に設定します:
server: tomcat: threads: # 最少线程数 min-spare: 10 # 最多线程数 max: 15 # 最大连接数 max-connections: 30 # 最大等待数 accept-count: 10
シンプルなインターフェイスを作成しましょう:
@GetMapping("/test") public Response test1(HttpServletRequest request) throws Exception { log.info("ip:{},线程:{}", request.getRemoteAddr(), Thread.currentThread().getName()); Thread.sleep(500); return Response.buildSuccess(); }
コードは非常に単純で、スレッド名を出力するだけです。その後、0.5 秒間スリープします。これにより、確実にいくつかのリクエストが一度に処理され、待機キューに入ります。
次に、Apifox を使用して 100 のリクエストをシミュレートするテスト ケースを作成しました。
#テスト結果を観察します。
結果からわかるように、設定された max-connections accept-count の合計は 40 であるため、60 個のリクエストが破棄され、これは予想と一致しています。最大スレッドは 15 であるため、最初に 25 個のリクエストが待機され、最初の 15 個が処理された後に 15 個が処理され、最後に 10 個が処理されます。つまり、40 個のリクエストは 3 つのバッチに分割されます。 15、15、10.を扱います。
#コンソールの印刷ログから、最大スレッド数が 15 であることがわかります。これは、前の考えを裏付けるものでもあります。
要約すると、: 同時リクエストの数が server.tomcat.threads.max よりも少ない場合、それはすぐに処理され、超過したリクエストは待機されます。その数が max-connection と accept-count の合計を超えた場合、超過分は直接破棄されます。
これまでのところ、SpringBoot が同時に処理できるリクエストの数を把握しました。ただし、ここでは上記の例に基づいて拡張したいと思います。同時シナリオの一部の値が予想したものと異なるのはそのためです。
设想有以下场景:厨师们用一个账本记录一共做了多少道菜,每个厨师做完菜都记录一下,每次记录都是将账本上的数字先抄到草稿纸上,计算x+1等于多少,然后将计算的结果写回到账本上。
Spring容器中的Bean默认是单例的,也就是说,处理请求的Controller、Service实例就只有一份。在并发场景下,将cookSum定义为全局变量,是所有线程共享的,当一个线程读到了cookSum=20,然后计算,写回前另一个线程也读到是20,两个线程都加1后写回,最终cookSum就变成了21,但是实际上应该是22,因为加了两次。
private int cookSum = 0; @GetMapping("/test") public Response test1(HttpServletRequest request) throws Exception { // 做菜。。。。。。 cookSum += 1; log.info("做了{}道菜", cookSum); Thread.sleep(500); return Response.buildSuccess(); }
以上がSpringBoot は同時にいくつのリクエストを処理できますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。