兩台筆記本網線直連，通過測速工具（jperf）測試，确定兩台電腦之間的資料傳輸速度可以達到1gbps，即千兆網卡的最大速度。兩台電腦硬體配置如下：
client伺服器，cpu：intel i5-3230 2.6ghz 記憶體：8g
server伺服器，cpu：intel i5-3210 2.5ghz 記憶體：4g
oneway表示client将資料通過socket發送後不關心server的處理結果，這種模式類似于push-pull的通信方式；
async表示client将資料發送到server後異步等待server的處理結果；
sync表示client将資料發送到server後同步等待server的處理結果；
由于sync的方式效率較低，且因為enode中使用通信層隻會用到oneway和async兩種方式；是以我隻測試了oneway, async這兩種通信模式。
說明：
理論上如果兩台電腦之間的帶寬是千兆，即1gbps，即125mb的話，那假設一個消息大小是1kb，那如果發送者和接收者的cpu和記憶體不會成為瓶頸，那理論上每秒應該可以發送接收125 * 1024 = 128000/s。
關于用戶端數量是指在client機器上開幾個程序進行發送消息，目前我是一個程序一個tcp連接配接。
大家可以看到，當消息大小為1k時，用戶端機器4個程序同時發送，服務端機器全部接收完用時39.5s，也就是每秒101265接近網卡的極限。為什麼沒有達到網卡的極限，其實可以到達隻要我開6個程序發送消息即可。隻是我上面為了友善對比，每個消息大小最多開4個程序。
測試過程中，我發現用戶端向服務端發送資料的吞吐量，主要的瓶頸還是在cpu。如果cpu好，那發送速度會很快，直到把網卡壓滿位置。
在消息大小為2k時，我沒有測試4個程序同時發送消息的場景，因為記憶體不夠用了。
大家可以看到async的通信模式，性能下降很多。是因為async要比oneway的方式，在邏輯上要多很多邏輯。比如發送前要先把一個taskcompletionsource加入到一個concurrentdictionary中，然後當對應的remotingrequest有回複時，擷取到對應的taskcompletionsource，然後設定回複結果，進而讓發送資料的task完成。以此實作異步發送資料的過程。
測試async的過程中，我發現假如瞬間假如100w個taskcompletionsource到concurrentdictionary，然後通過socket進行異步發送資料，一開始cpu會壓力非常大；是以我為了降低cpu的瓶頸，讓每個用戶端隻發送50w資料；
從上面的測試結果可以看出，1k大小的資料，async模式發送，吞吐量最大在3.3w。經過我的分析，主要的瓶頸還是在cpu。因為此時cpu基本接近極限，而網卡隻跑了250mb左右。說明我們應該盡量優化cpu的使用率，減少并發沖突。将來我準備使用disruptor.net來嘗試看看是否能提高async模式的性能。
在消息大小在1k和2k的情況下，我沒有測試用戶端數量為4的情況，因為此時client端機器的cpu，記憶體都已經成為瓶頸，沒必要測試了。實際上，在用戶端程序數量在3的時候，也已經成為瓶頸。
接下來準備再阿裡雲ecs伺服器上再做一下類似的測試，之前簡單摸底了一下。購買了兩台ecs虛拟機，配置都是4核8g記憶體。通過内網ip進行tcp測試（使用jperf工具）。發現兩台虛拟機之間，最大隻能達到60mb的速度。這說明，阿裡雲的ecs伺服器之間，帶寬無法達到125mb，比較遺憾。但這也是我未來希望部署enode案例的真實伺服器，是以在這個環境上的測試結果，應該更具參考價值。
大概知道通信層的性能之後，我準備對equeue發送消息和接收做性能測試。這個測試結果，就是決定enode各個節點之間，消息傳遞吞吐量的主要依據。