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

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

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

?

并發量是當前保持的連接數

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

轉載于:https://www.cnblogs.com/austinspark-jessylu/p/9414464.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。