秒懂QPS、TPS、PV、UV、GMV、IP、RPS

藍(lán)隊(duì)云小課堂：

QPS

Queries Per Second，每秒查詢(xún)數(shù)。每秒能夠響應(yīng)的查詢(xún)次數(shù)。

QPS 是一臺(tái)服務(wù)器每秒能夠相應(yīng)的查詢(xún)次數(shù)，即1秒內(nèi)完成的請(qǐng)求數(shù)量，是對(duì)一個(gè)特定的查詢(xún)服務(wù)器在規(guī)定時(shí)間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)

QPS是對(duì)一個(gè)特定的查詢(xún)服務(wù)器在規(guī)定時(shí)間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)，在因特網(wǎng)上，作為域名系統(tǒng)服務(wù)器的機(jī)器的性能經(jīng)常用每秒查詢(xún)率來(lái)衡量。每秒的響應(yīng)請(qǐng)求數(shù)，也即是最大吞吐能力。

TPS

Transactions Per Second 的縮寫(xiě)，每秒處理的事務(wù)數(shù)目。一個(gè)事務(wù)是指一個(gè)客戶(hù)機(jī)向服務(wù)器發(fā)送請(qǐng)求然后服務(wù)器做出反應(yīng)的過(guò)程。客戶(hù)機(jī)在發(fā)送請(qǐng)求時(shí)開(kāi)始計(jì)時(shí)，收到服務(wù)器響應(yīng)后結(jié)束計(jì)時(shí)，以此來(lái)計(jì)算使用的時(shí)間和完成的事務(wù)個(gè)數(shù)，最終利用這些信息作出的評(píng)估分。

TPS 的過(guò)程包括：客戶(hù)端請(qǐng)求服務(wù)端、服務(wù)端內(nèi)部處理、服務(wù)端返回客戶(hù)端。

例如，訪問(wèn)一個(gè) Index 頁(yè)面會(huì)請(qǐng)求服務(wù)器 3 次，包括一次 html，一次 css，一次 js，那么訪問(wèn)這一個(gè)頁(yè)面就會(huì)產(chǎn)生一個(gè)“T”，產(chǎn)生三個(gè)“Q”。

QPS 與 TPS 區(qū)別

QPS基本類(lèi)似于TPS，但是不同的是，對(duì)于一個(gè)Web頁(yè)面的一次訪問(wèn)，形成一個(gè)TPS（就做一件事兒，打開(kāi)Web網(wǎng)頁(yè)）；但一次Web頁(yè)面請(qǐng)求，可能產(chǎn)生多次對(duì)服務(wù)器的請(qǐng)求（html、css、js、images、files等），服務(wù)器對(duì)這些請(qǐng)求，就可計(jì)入QPS之中。每秒查詢(xún)率QPS是對(duì)一個(gè)特定的查詢(xún)服務(wù)器在規(guī)定時(shí)間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)。

一個(gè)事務(wù)是指一個(gè)客戶(hù)機(jī)向服務(wù)器發(fā)送請(qǐng)求然后服務(wù)器做出反應(yīng)的過(guò)程。客戶(hù)機(jī)在發(fā)送請(qǐng)求時(shí)開(kāi)始計(jì)時(shí)，收到服務(wù)器響應(yīng)后結(jié)束計(jì)時(shí)，以此來(lái)計(jì)算使用的時(shí)間和完成的事務(wù)個(gè)數(shù)。

如果是對(duì)一個(gè)接口（單場(chǎng)景）壓測(cè)，且這個(gè)接口內(nèi)部不會(huì)再去請(qǐng)求其它接口，那么TPS等于QPS，否則，若這個(gè)接口內(nèi)部還會(huì)再去請(qǐng)求其它接口（下載圖片、文件等服務(wù)器接口），那么 TPS不等于QPS，通常是 QPS會(huì)大于TPS

PV

page view即頁(yè)面瀏覽量

通常是衡量一個(gè)網(wǎng)絡(luò)新聞?lì)l道或網(wǎng)站甚至一條網(wǎng)絡(luò)新聞的主要指標(biāo)。

用戶(hù)每一次對(duì)網(wǎng)站中的每個(gè)頁(yè)面訪問(wèn)均被記錄 1 次。

用戶(hù)對(duì)同一頁(yè)面的多次刷新，訪問(wèn)量累計(jì)。

根據(jù)這個(gè)特性，刷網(wǎng)站的 PV 就很好刷了。

與 PV 相關(guān)的還有 RV，即重復(fù)訪問(wèn)者數(shù)量（repeat visitors）。

UV

Unique Visitor 指獨(dú)立訪客訪問(wèn)數(shù)，統(tǒng)計(jì)1天內(nèi)訪問(wèn)某站點(diǎn)的用戶(hù)數(shù)(以 cookie 為依據(jù))，一臺(tái)電腦終端為一個(gè)訪客。

IP

Internet Protocol獨(dú)立 IP 數(shù)

是指 1 天內(nèi)多少個(gè)獨(dú)立的 IP 瀏覽了頁(yè)面，即統(tǒng)計(jì)不同的 IP 瀏覽用戶(hù)數(shù)量。

同一 IP 不管訪問(wèn)了幾個(gè)頁(yè)面，獨(dú)立 IP 數(shù)均為 1；

不同的 IP 瀏覽頁(yè)面，計(jì)數(shù)會(huì)加 1。

IP 是基于用戶(hù)廣域網(wǎng) IP 地址來(lái)區(qū)分不同的訪問(wèn)者的，所以，多個(gè)用戶(hù)（多個(gè)局域網(wǎng) IP）在同一個(gè)路由器（同一個(gè)廣域網(wǎng) IP）內(nèi)上網(wǎng)，可能被記錄為一個(gè)獨(dú)立 IP 訪問(wèn)者。如果用戶(hù)不斷更換 IP，則有可能被多次統(tǒng)計(jì)。

RT

Response Time 響應(yīng)時(shí)間是一個(gè)系統(tǒng)最重要的指標(biāo)之一，它的數(shù)值大小直接反應(yīng)了系統(tǒng)的快慢。

響應(yīng)時(shí)間是指系統(tǒng)對(duì)請(qǐng)求作出響應(yīng)的時(shí)間。直觀上看，這個(gè)指標(biāo)與人對(duì)軟件性能的主觀感受是非常一致的，因?yàn)樗暾赜涗浟苏麄€(gè)計(jì)算機(jī)系統(tǒng)處理請(qǐng)求的時(shí)間。由于一個(gè)系統(tǒng)通常會(huì)提供許多功能，而不同功能的處理邏輯也千差萬(wàn)別，因而不同功能的響應(yīng)時(shí)間也不盡相同，甚至同一功能在不同輸入數(shù)據(jù)的情況下響應(yīng)時(shí)間也不相同。所以，在討論一個(gè)系統(tǒng)的響應(yīng)時(shí)間時(shí)，人們通常是指該系統(tǒng)所有功能的平均時(shí)間或者所有功能的最大響應(yīng)時(shí)間。當(dāng)然，往往也需要對(duì)每個(gè)或每組功能討論其平均響應(yīng)時(shí)間和最大響應(yīng)時(shí)間。

對(duì)于單機(jī)的沒(méi)有并發(fā)操作的應(yīng)用系統(tǒng)而言，人們普遍認(rèn)為響應(yīng)時(shí)間是一個(gè)合理且準(zhǔn)確的性能指標(biāo)。需要指出的是，響應(yīng)時(shí)間的絕對(duì)值并不能直接反映軟件的性能的高低，軟件性能的高低實(shí)際上取決于用戶(hù)對(duì)該響應(yīng)時(shí)間的接受程度。對(duì)于一個(gè)游戲軟件來(lái)說(shuō)，響應(yīng)時(shí)間小于100毫秒應(yīng)該是不錯(cuò)的，響應(yīng)時(shí)間在1秒左右可能屬于勉強(qiáng)可以接受，如果響應(yīng)時(shí)間達(dá)到3秒就完全難以接受了。而對(duì)于編譯系統(tǒng)來(lái)說(shuō)，完整編譯一個(gè)較大規(guī)模軟件的源代碼可能需要幾十分鐘甚至更長(zhǎng)時(shí)間，但這些響應(yīng)時(shí)間對(duì)于用戶(hù)來(lái)說(shuō)都是可以接受的。

響應(yīng)時(shí)間是指執(zhí)行一個(gè)請(qǐng)求從開(kāi)始到最后收到響應(yīng)數(shù)據(jù)所花費(fèi)的總體時(shí)間,即從客戶(hù)端發(fā)起請(qǐng)求到收到服務(wù)器響應(yīng)結(jié)果的時(shí)間

GMV

Gross Merchandise Volume 的簡(jiǎn)稱(chēng)。只要是訂單，不管消費(fèi)者是否付款、賣(mài)家是否發(fā)貨、是否退貨，都可放進(jìn) GMV 。

RPS

RPS 代表吞吐率，即 Requests Per Second 的縮寫(xiě)。吞吐率是服務(wù)器并發(fā)處理能力的量化描述，單位是 reqs/s，指的是某個(gè)并發(fā)用戶(hù)數(shù)下單位時(shí)間內(nèi)處理的請(qǐng)求數(shù)。

某個(gè)并發(fā)用戶(hù)數(shù)下單位時(shí)間內(nèi)能處理的最大的請(qǐng)求數(shù)，稱(chēng)之為最大吞吐率。

有人把 RPS 說(shuō)等效于 QPS。其實(shí)可以看作同一個(gè)統(tǒng)計(jì)方式，只是叫法不同而已。RPS/QPS，可以使用 apche ab 工具進(jìn)行測(cè)量。

QPS、PV 、RT 之間的關(guān)系

在進(jìn)行系統(tǒng)性能壓測(cè)和系統(tǒng)性能優(yōu)化的時(shí)候，會(huì)涉及到QPS,PV,RT相關(guān)的概念， QPS,PV,RT之間的關(guān)系

• 對(duì)于大部分web系統(tǒng)，響應(yīng)時(shí)間一般由CPU執(zhí)行時(shí)間，線程等待時(shí)間（IO等待，sleep, wait）時(shí)間組成，QPS和RT成反比關(guān)系

• 在實(shí)際的測(cè)試環(huán)境中，QPS和RT并不是非常直接的反比關(guān)系

QPS 是什么

QPS：?jiǎn)蝹€(gè)進(jìn)程每秒請(qǐng)求服務(wù)器的成功次數(shù) QPS = req/sec = 請(qǐng)求數(shù)/秒

QPS如何統(tǒng)計(jì)

QPS統(tǒng)計(jì)方式 [一般使用 http_load 進(jìn)行統(tǒng)計(jì)] QPS = 總請(qǐng)求數(shù) / ( 進(jìn)程總數(shù) * 請(qǐng)求時(shí)間 )

根據(jù)QPS推算PV：

單臺(tái)服務(wù)器每天PV計(jì)算:

公式1：每天總PV = QPS * 3600 * 6 公式2：每天總PV = QPS * 3600 * 8

根據(jù)QPS，PV推算服務(wù)器數(shù)量

服務(wù)器數(shù)量 = 每天總PV / 單臺(tái)服務(wù)器每天總PV

峰值QPS和機(jī)器計(jì)算公式：

原理：每天80%的訪問(wèn)集中在20%的時(shí)間里，這20%時(shí)間叫做峰值時(shí)間

峰值時(shí)間每秒請(qǐng)求數(shù)(QPS)：( 總PV數(shù) * 80% ) / ( 每天秒數(shù) * 20% )

峰值機(jī)器數(shù)量：峰值時(shí)間QPS / 單臺(tái)機(jī)器的QPS

例子：

問(wèn)：每天300w PV 的在單臺(tái)機(jī)器上，這臺(tái)機(jī)器需要多少Q(mào)PS？

答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

問(wèn)：如果一臺(tái)機(jī)器的QPS是58，需要幾臺(tái)機(jī)器來(lái)支持？

答：139 / 58 = 3

• 對(duì)于大部分web系統(tǒng)，響應(yīng)時(shí)間一般由CPU執(zhí)行時(shí)間，線程等待時(shí)間（IO等待，sleep, wait）時(shí)間組成，QPS和RT成反比關(guān)系

• 在實(shí)際的測(cè)試環(huán)境中，QPS和RT并不是非常直接的反比關(guān)系

最佳線程數(shù)

性能壓測(cè)的情況下，起初隨著用戶(hù)數(shù)的增加，QPS會(huì)上升，當(dāng)?shù)搅艘欢ǖ拈y值之后，用戶(hù)數(shù)量增加QPS并不會(huì)增加，或者增加不明顯，同時(shí)請(qǐng)求的響應(yīng)時(shí)間卻大幅增加，這個(gè)閥值我們認(rèn)為是最佳線程數(shù)。

剛好消耗完服務(wù)器的瓶頸資源的臨界線程數(shù)，公式如下

最佳線程數(shù)量 =（（線程等待時(shí)間 + 線程CPU執(zhí)行時(shí)間）/ 線程CPU執(zhí)行時(shí)間）* CPU數(shù)量

特性：

• 在達(dá)到最佳線程數(shù)的時(shí)候，線程數(shù)量繼續(xù)遞增，則QPS不變，而響應(yīng)時(shí)間變長(zhǎng)，持續(xù)遞增線程數(shù)量，則QPS開(kāi)始下降

• 每個(gè)系統(tǒng)都有其最佳線程數(shù)量，但是不同狀態(tài)下，最佳線程數(shù)量是會(huì)變化的

• 瓶頸資源可以是CPU,可以是內(nèi)存，可以是鎖資源，IO資源

超過(guò)最佳線程數(shù)，會(huì)導(dǎo)致資源的競(jìng)爭(zhēng)；超過(guò)最佳線程數(shù)，會(huì)響應(yīng)時(shí)間遞增。

為什么要找最佳線程數(shù)

• 過(guò)多的線程只會(huì)造成，更多的內(nèi)存開(kāi)銷(xiāo)，更多的CPU開(kāi)銷(xiāo)，但是對(duì)提升QPS確毫無(wú)幫助

• 找到最佳線程數(shù)后通過(guò)簡(jiǎn)單的設(shè)置，可以讓web系統(tǒng)更加穩(wěn)定，得到最高，最穩(wěn)定的QPS輸出

最佳線程數(shù)的獲取：

• 通過(guò)用戶(hù)慢慢遞增來(lái)進(jìn)行性能壓測(cè)，觀察QPS，響應(yīng)時(shí)間

• 根據(jù)公式計(jì)算:服務(wù)器端最佳線程數(shù)量=((線程等待時(shí)間+線程cpu時(shí)間)/線程cpu時(shí)間) *      cpu數(shù)量

• 單用戶(hù)壓測(cè)，查看CPU的消耗，然后直接乘以百分比，再進(jìn)行壓測(cè)，一般這個(gè)值的附近應(yīng)該就是最佳線程數(shù)量。      

影響最佳線程數(shù)的主要因素

• IO

IO開(kāi)銷(xiāo)較多的應(yīng)用其CPU線程等待時(shí)間會(huì)比較長(zhǎng)，所以線程數(shù)量可以開(kāi)的多一些，相反則線程數(shù)量要少一些，其實(shí)有兩種極端，純IO的應(yīng)用，比如proxy，則線程數(shù)量可以開(kāi)到非常大（實(shí)在太大了則需要考慮線程切換的開(kāi)銷(xiāo)），這種應(yīng)用基本上后端（比如這個(gè)proxy是代理搜索的）的QPS能有多少，proxy就有多少。

• CPU

對(duì)于耗CPU的計(jì)算，這種情況一般來(lái)講只能開(kāi)到CPU個(gè)數(shù)的線程數(shù)量。但是并不是說(shuō)這種應(yīng)用的QPS就不高，往往這種應(yīng)用的QPS可以很高，因?yàn)楹腃PU計(jì)算的應(yīng)用，往往處理單次請(qǐng)求的時(shí)間會(huì)很短。

QPS和線程數(shù)的關(guān)系

在最佳線程數(shù)量之前，QPS和線程是互相遞增的關(guān)系，線程數(shù)量到了最佳線程之后，QPS持平，不在上升，甚至略有下降，同時(shí)響應(yīng)時(shí)間持續(xù)上升。

同一個(gè)系統(tǒng)而言，最佳線程數(shù)越多，QPS越高

并發(fā)數(shù)**（**Parallels）

并發(fā)數(shù)是指系統(tǒng)同時(shí)能處理的請(qǐng)求數(shù)量，一般跟CPU個(gè)數(shù)，線程數(shù)有關(guān)，這反應(yīng)了系統(tǒng)的負(fù)載能力

并發(fā)用戶(hù)數(shù)是指系統(tǒng)可以同時(shí)承載的正常使用系統(tǒng)功能的用戶(hù)的數(shù)量。與吞吐量相比，并發(fā)用戶(hù)數(shù)是一個(gè)更直觀但也更籠統(tǒng)的性能指標(biāo)。實(shí)際上，并發(fā)用戶(hù)數(shù)是一個(gè)非常不準(zhǔn)確的指標(biāo)，因?yàn)橛脩?hù)不同的使用模式會(huì)導(dǎo)致不同用戶(hù)在單位時(shí)間發(fā)出不同數(shù)量的請(qǐng)求。一網(wǎng)站系統(tǒng)為例，假設(shè)用戶(hù)只有注冊(cè)后才能使用，但注冊(cè)用戶(hù)并不是每時(shí)每刻都在使用該網(wǎng)站，因此具體一個(gè)時(shí)刻只有部分注冊(cè)用戶(hù)同時(shí)在線，在線用戶(hù)就在瀏覽網(wǎng)站時(shí)會(huì)花很多時(shí)間閱讀網(wǎng)站上的信息，因而具體一個(gè)時(shí)刻只有部分在線用戶(hù)同時(shí)向系統(tǒng)發(fā)出請(qǐng)求。這樣，對(duì)于網(wǎng)站系統(tǒng)我們會(huì)有三個(gè)關(guān)于用戶(hù)數(shù)的統(tǒng)計(jì)數(shù)字：注冊(cè)用戶(hù)數(shù)、在線用戶(hù)數(shù)和同時(shí)發(fā)請(qǐng)求用戶(hù)數(shù)。由于注冊(cè)用戶(hù)可能長(zhǎng)時(shí)間不登陸網(wǎng)站，使用注冊(cè)用戶(hù)數(shù)作為性能指標(biāo)會(huì)造成很大的誤差。而在線用戶(hù)數(shù)和同事發(fā)請(qǐng)求用戶(hù)數(shù)都可以作為性能指標(biāo)。相比而言，以在線用戶(hù)作為性能指標(biāo)更直觀些，而以同時(shí)發(fā)請(qǐng)求用戶(hù)數(shù)作為性能指標(biāo)更準(zhǔn)確些。

吞吐量**（**Throughput）

吞吐量是指單位時(shí)間內(nèi)系統(tǒng)能處理的請(qǐng)求數(shù)量，體現(xiàn)系統(tǒng)處理請(qǐng)求的能力，這是目前最常用的性能測(cè)試指標(biāo)

吞吐量是指系統(tǒng)在單位時(shí)間內(nèi)處理請(qǐng)求的數(shù)量。對(duì)于無(wú)并發(fā)的應(yīng)用系統(tǒng)而言，吞吐量與響應(yīng)時(shí)間成嚴(yán)格的反比關(guān)系，實(shí)際上此時(shí)吞吐量就是響應(yīng)時(shí)間的倒數(shù)。前面已經(jīng)說(shuō)過(guò)，對(duì)于單用戶(hù)的系統(tǒng)，響應(yīng)時(shí)間（或者系統(tǒng)響應(yīng)時(shí)間和應(yīng)用延遲時(shí)間）可以很好地度量系統(tǒng)的性能，但對(duì)于并發(fā)系統(tǒng)，通常需要用吞吐量作為性能指標(biāo)。

對(duì)于一個(gè)多用戶(hù)的系統(tǒng)，如果只有一個(gè)用戶(hù)使用時(shí)系統(tǒng)的平均響應(yīng)時(shí)間是t，當(dāng)有你n個(gè)用戶(hù)使用時(shí)，每個(gè)用戶(hù)看到的響應(yīng)時(shí)間通常并不是n×t，而往往比n×t小很多（當(dāng)然，在某些特殊情況下也可能比n×t大，甚至大很多）。這是因?yàn)樘幚砻總€(gè)請(qǐng)求需要用到很多資源，由于每個(gè)請(qǐng)求的處理過(guò)程中有許多不走難以并發(fā)執(zhí)行，這導(dǎo)致在具體的一個(gè)時(shí)間點(diǎn)，所占資源往往并不多。也就是說(shuō)在處理單個(gè)請(qǐng)求時(shí)，在每個(gè)時(shí)間點(diǎn)都可能有許多資源被閑置，當(dāng)處理多個(gè)請(qǐng)求時(shí)，如果資源配置合理，每個(gè)用戶(hù)看到的平均響應(yīng)時(shí)間并不隨用戶(hù)數(shù)的增加而線性增加。實(shí)際上，不同系統(tǒng)的平均響應(yīng)時(shí)間隨用戶(hù)數(shù)增加而增長(zhǎng)的速度也不大相同，這也是采用吞吐量來(lái)度量并發(fā)系統(tǒng)的性能的主要原因。一般而言，吞吐量是一個(gè)比較通用的指標(biāo)，兩個(gè)具有不同用戶(hù)數(shù)和用戶(hù)使用模式的系統(tǒng)，如果其最大吞吐量基本一致，則可以判斷兩個(gè)系統(tǒng)的處理能力基本一致。

并發(fā)量、QPS、RT 之間的關(guān)系：

QPS = 并發(fā)量 / 平均響應(yīng)時(shí)間 （推薦）

并發(fā)量 = QPS * 平均響應(yīng)時(shí)間

假設(shè)每天80%的訪問(wèn)集中在20%的時(shí)間里，這20%時(shí)間叫做峰值時(shí)間

公式：( 總PV數(shù) * 80% ) / ( 每天秒數(shù) * 20% ) = 峰值時(shí)間每秒請(qǐng)求數(shù)(QPS)

機(jī)器：峰值時(shí)間每秒QPS / 單臺(tái)機(jī)器的QPS = 需要的機(jī)器

每天300w PV 的在單臺(tái)機(jī)器上，這臺(tái)機(jī)器需要多少Q(mào)PS？

( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

如果一臺(tái)機(jī)器的QPS是58，需要幾臺(tái)機(jī)器來(lái)支持？

139 / 58 = 3 （進(jìn)一法，取上限）

單線程QPS公式，QPS=1000ms/RT,對(duì)同一個(gè)系統(tǒng)而言，支持的線程數(shù)越多，QPS越高。

假設(shè)一個(gè)RT是80ms,則可以很容易的計(jì)算出QPS,QPS = 1000/80 = 12.5

多線程場(chǎng)景，如果把服務(wù)端的線程數(shù)提升到2，那么整個(gè)系統(tǒng)的QPS則為 2*（1000/80） = 25,

可見(jiàn)QPS隨著線程的增加而線性增長(zhǎng)，那QPS上不去就加線程唄，聽(tīng)起來(lái)很有道理，公司也說(shuō)的通，但是往往現(xiàn)實(shí)并非如此。

如何提升RT（響應(yīng)時(shí)間）

• 減少 IO 的響應(yīng)時(shí)間，減少 IO 的調(diào)用次數(shù)

并發(fā)HTTP請(qǐng)求，無(wú)上下文依賴(lài)，多個(gè)連接，一個(gè)線程

HTTP連接池（長(zhǎng)連接，keep-alive）

• 減少 CPU 的使用時(shí)間

forest 循環(huán)的例子

如何提升 QPS（每秒查詢(xún)數(shù)）

• 減少 CPU 的使用時(shí)間

• 增加 CPU 的數(shù)量

• 減少同步鎖

如果 CPU 不能被壓到 85% 以上，并且此時(shí)的OPS已經(jīng)達(dá)到了峰值，則說(shuō)明另有瓶頸，接下去要重點(diǎn)關(guān)注內(nèi)存

排查內(nèi)存是否有瓶頸

判斷依據(jù)，是在最佳線程數(shù)量 * 5 左右的情況下，進(jìn)行壓測(cè)，觀察 Old 區(qū)內(nèi)存增長(zhǎng)是否正常

性能壓測(cè)要關(guān)注使用了多少用戶(hù)數(shù)，目前的壓測(cè)方式容易遺漏內(nèi)存瓶頸

總結(jié)

• Proxy 應(yīng)用（耗IO）的線程越多越好，當(dāng)線程達(dá)到過(guò)多時(shí)，線程本身資源的開(kāi)銷(xiāo)也會(huì)成為瓶頸，線程本身也是一個(gè)資源。

所以這類(lèi)Proxy應(yīng)用一般采取輕程模型，NIO解決，如 nginx

• 計(jì)算型應(yīng)用（耗CPU），線程數(shù)量就是CPU的核數(shù)，如搜索索引服務(wù)器，需要做大量的計(jì)算排序，非常耗CPU資源

更多小知識(shí)，可聯(lián)系藍(lán)隊(duì)云一起探討。