設(shè)平均響應(yīng)時間為t(單位為毫秒), 并發(fā)量為c，每秒處理請求數(shù)為q，則：?
q = (1000/t) * c?
就是這個關(guān)系；?
想要升高q，就只有兩條路：1) 降低t 2) 升高c?
對于'1', 只能靠優(yōu)化代碼實現(xiàn)，只能盡量做，往往提升有限；?
對于'2', 通常c與你服務(wù)器程序的請求處理模型有關(guān)，如果你服務(wù)器程序是“一個線程對應(yīng)一個請求”的模式，那么c的最大值就受制于你能支撐多少個線程；如果是“一個進程對應(yīng)一個請求”的模式，那么c的最大值則受制于最大進程數(shù)；

在升高c的過程中，不得不注意的一點是，線程/進程數(shù)越多，上下文切換、線程/進程調(diào)度開銷會增大，這會顯著間接地增大t的值從而不能讓q跟著c的值等比升高, 所以一味增大c通常也不會有好結(jié)果，最合適的c值應(yīng)該根據(jù)實測試驗得出

另外，還有一種特殊情況：若業(yè)務(wù)決定了該服務(wù)器提供的服務(wù)具有“小數(shù)據(jù)量、較長返回時間”的特征，即這是一個不忙、但很慢的業(yè)務(wù)類型，那么可以采用NIO模式提供服務(wù)，比如nginx默認就采用nio模式；?
在這種模式下，c值不再與線程/進程數(shù)相關(guān)，而僅僅與“socket連接數(shù)”相關(guān)，通?！皊ocket連接數(shù)”可以非常大，在經(jīng)過特殊配置的linux服務(wù)器上，可以同時支撐百萬級別的socket連接數(shù)，在這種情況下c可以達到100w;?
在如此高的c值之下，就算t再大，也可以支撐出一個很高的q，同時真正的線程/進程數(shù)可以只開到跟cpu核數(shù)一致，以求最大化cpu利用率;?
當(dāng)然這一切的前提是該業(yè)務(wù)具有“小數(shù)據(jù)量、較長返回時間”的特征

?

并發(fā)量是當(dāng)前保持的連接數(shù)

?netstat -ntp | grep -i "6661" | wc -l
(No info could be read for "-p": geteuid()=512 but you should be root.)
89

轉(zhuǎn)載于:https://www.cnblogs.com/austinspark-jessylu/p/9414464.html

總結(jié)

以上是生活随笔為你收集整理的每秒处理请求数和并发的关系的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。