測試TCP server的QPS的合適方法？

12-28

請教各位大大：
場景：
TCP server，接收client的請求，沒有應答
TCP client，單純地向client發送請求

這種僅有req無rsp的場景下，測試QPS的合適方法是什麼？

1、結構及流程
　　A、看守線程負責響應接受投遞不足時的事件並投遞接受請求，同是處理空連接和心跳超時
　　B、工作線程負責處理讀寫完成及讀寫錯誤的處理，並投遞給處理線程
　　C、由於在工作處理數據及進行文件和資料庫讀寫等操作可能會造成通信「卡」的現象，因此增加了處理線程，通過完成隊列和線程池，接受工作線程投遞過來的事件，處理線程通過回調函數將IO操作結果傳遞給應用層，應用層完全可以在回調函數里處理數據，從而實現了0拷貝功能，並保證數據的有序處理。

2、運行信息
　　為能更好的測試模塊，開發者可參考截圖的信息內容，對自己的模塊進行測試開發工作，以幫助觀察運行情況判斷問題所在。

Server 有個 counter，記錄目前處理完的請求數，然後每秒鐘輸出一下 counter 的值。

https://github.com/atframework/libatbus/tree/master/tools
要麼你看下這裡面的代碼和腳本？

難得有空答一記好了。

1. 確定是長連接還是短連接
如果是長連接，那好辦做好keep alive和超時檢查就好了。（由於你的伺服器模型只有接收，在不發包給客戶端的情況下無法判斷對端是否不可達，所以要keepalive心跳檢查）
如果是短連接，那要小心timewait狀態，盡量不要讓伺服器主動關閉連接。客戶端關閉連接過於頻繁短時間內也會造成大量埠佔用。

2. 使用不同的客戶機和網路環境進行測試
tcp有窗口，擁塞控制，naggle演算法，cork演算法等調節機制，這既是優點也是缺點。不同的操作系統實現機制不同，由於大小端等問題解包效率也會受到影響，路由器對單一連接的路由表查找效率跟幾十萬不同連接的查找效率也不同，mtu大小也會造成拆包等問題，iptables過濾能力也不同，種種因素要求測試儘可能考慮各種外部情況。

3. 做好隨機性
客戶端連接頻率，發包頻率，出錯概率，關閉頻率最好做到隨機，以應對不同的情況。

4. 人為設置網路問題
現實中的網路肯定不如區域網那麼健壯，同樣的連接消息路由路徑往往都會不同，丟包也是不可避免。這時候就要人為設置發包延遲和丟包概率，檢查在網路環境較差的情況下tcp響應能力。甚至可以人為斷開網路測試icmp網路不可達消息是否正確由路由器返回及時通知伺服器關閉連接。

簡單的qps測試這樣就行了，設計問題比如包頭佔比，接收及時性，包解密效率等先不考慮。
如果是完整性網關測試，還要多接入點測試，syn flood預防，ddos預防，arp預防，故障恢復等測試，就不多說了。

線上做類似的測試統計最好用的是日誌統計法

如果解決實際問題，就用 @陳碩這個方案，最好了

如果就是單純的想問這個問題，我有一個辦法，不知道對不對，請大神門也幫忙看看，讓我也提高下

我的理解是，打滿服務端以後，客戶端會阻塞，這時候開始計數，就說明發一個服務端那邊就處理了一個。前提是你的各項設置都合理，確保服務端會阻塞客戶端發請求。

@陳碩請大神幫忙看下有何不妥之處