nginx - 每秒處理請求數和同時是個概念嗎？

Question

windows用apache的ab測試了伺服器

ab -c 100 -n 1000 http://www.xxxxx.com

發現 每秒處理請求數只有20，其他的等待 不是說nginx預設的並發量很高麼？

還是每秒處理請求數和並發不是一個概念。

每秒處理數 並發 壓力測試 求疏通。 。 。

Answer 1

只說一台伺服器的狀況。
並發數是指同時到達的請求數量，這是從客戶端的角度來說的；伺服器並發處理能力則是指伺服器能同時處理多少個請求，理想情況下（在無進程切換的情況下），並發處理能力等於cpu的核數。
基於上面說的，假如有8核，並且請求的任務都是無io的純計算任務，那明顯每個核每秒的處理能力不止一個請求，假設每秒能處理10000個（簡單的計算任務的話，這個數量完全是有可能的），那這台伺服器就能處理每秒80000的請求數。
現在再加上io，如果io的時候cpu必須等待，且不能做其他事，那顯然cpu每秒能處理的請求數將大大下降，可能會從10000個降到幾百個甚至幾十個或幾個。
接下來可以加上進程切換、演算法效率等各種因素，把這些因素一個一個加上去之後，就能得到一個複雜的但真實的伺服器了。

Answer 2

不是同一個概念，但它們之間有聯繫：
設平均回應時間為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利用率;
當然這一切的前提是該業務具有“小數據量、較長返回時間」的特徵

Answer 3

我們假設你的網站是一個靜態站，所有的請求都走nginx，然後需要確認測試機和伺服器的網路通訊要暢通。 ab這種工具對於壓力測試來說不是很有說服力，推薦jmeter或loadrunner。壓力測試的時候要確保測試的回應時間曲線穩定住一定時間後，才認為是目前被測試伺服器的真實效能，因為剛開始測試的時候需要一定預熱時間，一般測試到一定時間之後曲線會穩定住，這時候再判斷當前的回應時間。

Answer 4

每秒請求數 = 一段時間完成總的請求數 / 時間

並發量是目前保持的連線數吧，透過netstat -net 查看所有連線。

如：

netstat -ntp |grep -i "80" | wc -l