性能（壓力）測試單台電腦能模擬多少並發？

01-08

在做壓力測試的時候，通常使用多進程，多線程的方式來模擬多個終端。
但是，單台機器的並發能力有限，假設，正常的一個pc機，4核cpu,8G內存
啟動50個線程對伺服器並發訪問。跟真正的50個人並發訪問肯定是有區別的

那到底一台如上配置的機器能模擬多少並發？這裡面有什麼演算法？
能想到的是，真正的人去操作，可能還沒有線程切換的快，那假設換成tcp的長連接呢？

關鍵還是人的這個概念。普通人去訪問一個網站，打開一個url，這個url請求其實之後去載入了很多資源。而如果機器人只是模擬載入了html頭，沒有去載入css，png等資源文件。這兩者的性質肯定是差異很大的。

做壓力測試，不應該使用線程模式，應該儘可能採用非同步IO模式，所以50並發就是50個連接而已，而不是50個線程。

對於簡單測試而言，1台機器能模擬的並發量一般決定於可用內存量對於連接的支持，所以一般來說並發量在測試中是比較虛的參數。

一般來說，吞吐量(TPS)也就是每秒完成任務數量，才是測試中的重要參數，另外響應時間也是一個有意義的參數。

在我做過的簡單測試中，對於web壓力測試而言，短連接的CPU開銷大概是長連接的3倍左右。

但是如果換做是TCP長連接，可以在框架層面做成批量處理模式，減少通訊次數，那麼開銷差距是可能相差100倍甚至更多的。

剛好我的工作機也是4核(i5-4570)，不過是16GB內存(但是在這個測試中沒有什麼意義)。

關於web壓力測試項目使用的是C#開源項目fastCSharp的demo.loadBalancingTcpCommandWeb項目。

測試中啟動5個進程，1個客戶端進程，1個HTTP服務進程，3個TCP負載均衡節點進程。

測試內容為計算兩個整數的和或者異或值，並在客戶端驗證計算結果。

測試流程為客戶端進程啟動1024個HTTP客戶端，採用非同步IO短連接模式對HTTP服務發起請求，隨機訪問HTTP服務端的8個調用介面，HTTP服務端把請求轉發到3個TCP計算節點並在獲取計算返回值以後返回給HTTP客戶端。

HTTP伺服器端支持 AJAX、WebView、WebCall、搜索引擎View 共4種訪問模式，每種訪問模式都同時支持同步與非同步兩種訪問模式，所以有8個調用介面。

可以看到測試結果穩定在2W+TPS。

但是你要知道，壓力測試僅僅反映測試環境中的相關參數的上限值，相對於實際環境是可能出現較大差距的。

我以LR為例，其實設置虛擬用戶對伺服器發送請求和真實用戶訪問是沒有什麼區別的，因為LR可以真實模擬用戶場景，而且錄製的腳本也是用戶真實的操作，要說到並發，我不知道LR設置並發用戶有沒有上限，不過幾十萬上百萬並發是可以的，而且LR安裝的時候是可以設置可設置的最大並發用戶是多少，你設置的並發用戶對伺服器發送請求，其實伺服器才是承受壓力最大的一方，跟你伺服器所在的設備有關，而不是客戶端，一般公司的電腦，設置幾萬，上十萬用戶並發，並且跑一個晚上腳本是沒問題的。

可以看看redis-benchmark

據我的經驗來說，4核16G的最多抗的住500

通常我設置的並發量在200-300之間每台

測試的結果不在用什麼模擬而在模擬了多深的業務邏輯！

這個結果需要伺服器端才能給出。