一、并發(fā)測(cè)試

1.1 代碼

SpringBoot可以同時(shí)處理多少請(qǐng)求？站在SpringBoot的角度來(lái)，確實(shí)可以通過(guò)一些配置來(lái)有效的去控制一次請(qǐng)求的連接數(shù)。比如控制100，一旦連接數(shù)超過(guò)100，客戶端就會(huì)顯示連接超時(shí)?？匆粋€(gè)簡(jiǎn)單的例子，我在這里創(chuàng)建了一個(gè)Springboot應(yīng)用，聲明了一個(gè)接口。里面很簡(jiǎn)單，就是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ù)的意思呢，后面會(huì)講到。

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

1.2 壓測(cè)

然后通過(guò)JMeter來(lái)給大家做一個(gè)壓測(cè)。我發(fā)起的線程數(shù)是100，qps相當(dāng)于是100，請(qǐng)求我們剛剛的那個(gè)接口?？梢钥吹酱藭r(shí)的這個(gè)異常數(shù)是60%，也就是我們的100請(qǐng)求當(dāng)中呢，只有40次成功了，其中60次是失敗的。結(jié)合剛剛這個(gè)參數(shù)來(lái)看一下，最大連接數(shù)加這個(gè)最大等待數(shù)的數(shù)量，40次成功了，剩下的60次呢是失敗了。

二、參數(shù)說(shuō)明

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

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

配置

三、詳解

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

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

大概的流程是這樣的。當(dāng)一個(gè)客戶進(jìn)來(lái)，我們首先會(huì)看一下這個(gè)最大連接數(shù)，是不是小于當(dāng)前連接數(shù)，也就是這個(gè)飯店里面到底能不能坐得下。如果能坐下的話，我們看一下最小工作線程數(shù)里面，這兩個(gè)廚師他是不是都閑著，如果都閑著的話，肯定就分配一個(gè)廚師去直接給我們炒菜了。那如果這兩個(gè)廚師，他都在為這兩桌客人在炒菜的話，那我們就需要去找到那些兼職的廚師來(lái)為我們?nèi)コ床恕３赐瓴?，整個(gè)流程就結(jié)束了。

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

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

那我們剛剛壓測(cè)的時(shí)候，為什么這60個(gè)都失敗了呢？其實(shí)是因?yàn)槲乙才渲昧艘粋€(gè)連接超時(shí)間是300ms，那我們的業(yè)務(wù)處理時(shí)間是2秒鐘，所以其余的60個(gè)肯定就超時(shí)了。我只能等待300ms，我的耐心就300ms，你如果這里面還沒人出來(lái)，我就直接走了。

實(shí)際我們?cè)诜?wù)器當(dāng)中，要去調(diào)整這幾個(gè)參數(shù)的話，得結(jié)合很多的指標(biāo)，比如說(shuō)我們服務(wù)器的硬件的性能，io模型，網(wǎng)絡(luò)，還要結(jié)合一些壓測(cè)，服務(wù)器的監(jiān)控，實(shí)際的數(shù)據(jù)，才能設(shè)置最佳性能的一個(gè)配置。

以上就是字節(jié)二面SpringBoot可以同時(shí)處理多少請(qǐng)求的詳細(xì)內(nèi)容，更多關(guān)于SpringBoot同時(shí)處理請(qǐng)求的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！