設平均響應時間為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
