一、并發(fā)測試

1.1 代碼

SpringBoot可以同時處理多少請求？站在SpringBoot的角度來，確實可以通過一些配置來有效的去控制一次請求的連接數(shù)。比如控制100，一旦連接數(shù)超過100，客戶端就會顯示連接超時?？匆粋€簡單的例子，我在這里創(chuàng)建了一個Springboot應用，聲明了一個接口。里面很簡單，就是sleep了兩秒。

@Slf4j
@RestController
@RequestMapping("test")
public class TestController {
    @GetMapping
    public String test() throws InterruptedException {
        log.info("線程:{}", Thread.currentThread().getName());
        Thread.sleep(2000);
        return "OK";
    }
}

然后我配置了連接池的一些參數(shù)，參數(shù)的意思呢，后面會講到。

server:
  tomcat:
    threads:
      min-spare: 10        # 最少線程數(shù)
      max: 20              # 最多線程數(shù)
    max-connections: 30    # 最大線程數(shù)
    accept-count: 10       # 最大等待數(shù)

1.2 壓測

然后通過JMeter來給大家做一個壓測。我發(fā)起的線程數(shù)是100，qps相當于是100，請求我們剛剛的那個接口。可以看到此時的這個異常數(shù)是60%，也就是我們的100請求當中呢，只有40次成功了，其中60次是失敗的。結合剛剛這個參數(shù)來看一下，最大連接數(shù)加這個最大等待數(shù)的數(shù)量，40次成功了，剩下的60次呢是失敗了。

二、參數(shù)說明

作為SpringBoot，我可以通過配置內嵌的這個tomcat的線程池的參數(shù)去控制它的請求數(shù)量，當我們問到SpringBoot可以同時處理多少請求的話，我們只需要知道這兩個參數(shù)它的默認值是多少，其實就是這個問題的答案了。

這幾個參數(shù)的默認值呢，我們打開這個spring配置原數(shù)據(jù)的json文件來進行查看，這份文件當中把SpringBoot所有的默認可配置項，都給我們列出來了。包括每一個配置項，它的說明、默認值都在上面。我們剛剛配置的這個最大連接數(shù)max-connections，它的默認值是8192，最大等待數(shù)是100，所以SpringBoot可以同時處理多少請求的答案呢，就是8192+100=8292。

配置

三、詳解

那在我們的一個高并發(fā)的應用當中，這幾個參數(shù)它需不需要改變呢？答案是肯定需要的。首先要搞清楚這幾個參數(shù)的意思，才能更好的去配置。

大家可以把我們的web服務器，當做是一個飯店，最小線程數(shù)當做飯店里面正式員工的廚師，最大線程數(shù)當做兼職廚師，最大連接數(shù)是我們這個飯店最多可以容納的客戶，最大等待數(shù)當作是最多可以多少人去排隊。

大概的流程是這樣的。當一個客戶進來，我們首先會看一下這個最大連接數(shù)，是不是小于當前連接數(shù)，也就是這個飯店里面到底能不能坐得下。如果能坐下的話，我們看一下最小工作線程數(shù)里面，這兩個廚師他是不是都閑著，如果都閑著的話，肯定就分配一個廚師去直接給我們炒菜了。那如果這兩個廚師，他都在為這兩桌客人在炒菜的話，那我們就需要去找到那些兼職的廚師來為我們去炒菜。炒完菜，整個流程就結束了。

像我們剛剛應用程序當中所示，我們的最大連接數(shù)呢配置的是30，最大等待數(shù)是10，最大工作線程數(shù)是20，最小工作線程數(shù)是10，然后我們的連接我們的qps是100，那這個過程是什么樣的呢？那首先這100個請求進來，我們會看一下最大連接數(shù)當中是不是有，我們會分配30個人坐到飯店里面去，然后呢還有10個人可以去排隊。那么其余的60個人他不會立馬走，會觀望一下，看還有沒有機會，所以這60個人會等待一個超時時間，如果在這個超時間之內，你這40個人有人出來，有人吃完了之后，我這60個人依然可以進去。如果這60個人耐心用光了，也就是我的超時時間用完了，就會顯示connect timeout，連接超時大概是一個這樣的過程。

這30個人進來之后，并不是說直接就有30個線程直接去處理，而是根據(jù)最大工作線程數(shù)來的。首先看一下最小線程數(shù)能不能滿足，如果最小線程數(shù)滿足的話，就不需要額外再開辟多余的線程去處理了。如果最小線程數(shù)滿足不了，就需要開辟多余的線程數(shù)來去幫我們炒菜。最大線程數(shù)我們配置是20個，那這30個呢首先會有20個來進行處理，其余的10個會放入到我們線程池的阻塞隊列當中，完了之后再處理這10個，最后處理排隊的這10個。如果這60個沒有超過這個連接超時時間的話，那這60個依然會進行處理。

那我們剛剛壓測的時候，為什么這60個都失敗了呢？其實是因為我也配置了一個連接超時間是300ms，那我們的業(yè)務處理時間是2秒鐘，所以其余的60個肯定就超時了。我只能等待300ms，我的耐心就300ms，你如果這里面還沒人出來，我就直接走了。

實際我們在服務器當中，要去調整這幾個參數(shù)的話，得結合很多的指標，比如說我們服務器的硬件的性能，io模型，網絡，還要結合一些壓測，服務器的監(jiān)控，實際的數(shù)據(jù)，才能設置最佳性能的一個配置。

以上就是字節(jié)二面SpringBoot可以同時處理多少請求的詳細內容，更多關于SpringBoot同時處理請求的資料請關注腳本之家其它相關文章！

最新評論