RDMA上的Java套接字（JSOR）與Infiniband中的jVerbs性能

Question

我對JSOR和jVerbs都有基本的瞭解。

兩者都處理JNI的限制並使用快速路徑來減少延遲。它們都使用用戶動詞RDMA接口來避免上下文切換並提供快速路徑訪問。兩者都可以選擇零拷貝傳輸。

區別在於JSOR仍然使用Java Socket接口。 jVerbs提供了一個新的界面。 jVerbs還有一些稱爲有狀態動詞調用的內容，以避免重複序列化RDMA請求，這些請求會減少延遲。 jVerbs提供更原生的界面，應用程序可以直接使用這些界面。我閱讀了jVerbs SoCC 2013論文，他們在jVerbs之上構建了jverbsRPC，並顯示它顯着減少了zookeeper和memcache操作的延遲。

兩者的文檔都表明它們比基於TCP/IP，SDP和IPoIB的常規Java套接字執行得更好。

我沒有JSOR和jVerbs之間的任何性能比較。 我認爲jVerbs可能比JSOR表現更好。但是，使用JSOR，我不必更改現有的代碼，因爲它仍然使用相同的Java套接字接口。我的問題是使用jVerbs相對於JSOR的性能收益。有沒有人知道或有經驗處理這兩個？如果你有任何比較數據會很好。我找不到任何東西。

Answer 1

下面是一些使用DiSNI（IBM的jVerbs的新開源代替）和DaRPC（使用DiSNI的低延遲RPC庫）的數字。

• DiSNI RDMA讀取64個字節等待時間低於2微秒
• DaRPC RDMA發送/ RECV延遲爲64個字節（請求和響應）是大約5微秒
• betwenn爪哇/ DiSNI和C原生的差異RDMA對於單向操作可忽略

這些基準測試已在使用Mellanox ConnectX-3網絡接口連接的兩臺主機上執行。

下面是執行基準的命令：

（1）讀取基準

服務器：

java -cp disni-1.0-jar-with-dependencies.jar:disni-1.0-tests.jar com.ibm.disni.examples.benchmarks.AppLauncher -t java-rdma-server -a <address> -o read -s 64 -k 100000 -p 

客戶：

java -cp disni-1.0-jar-with-dependencies.jar:disni-1.0-tests.jar com.ibm.disni.examples.benchmarks.AppLauncher -t java-rdma-client -a <address> -o read -s 64 -k 100000 -p 

（2）發送/ RECV基準

服務器：

java -cp darpc-1.0-jar-with-dependencies.jar:darpc-1.0-tests.jar com.ibm.darpc.examples.server.DaRPCServer -a <address> -d -l 64 -r 64 

客戶：

java -cp darpc-1.0-jar-with-dependencies.jar:darpc-1.0-tests.jar com.ibm.darpc.examples.client.DaRPCClient -a <address> -k 1000000 -l 64 -r 64 -b 1 

Answer 2

比較jVerbs與JSOR的性能有點難。第一個是面向消息的API，第二個隱藏了Java套接字基於流的API背後的RDMA。

以下是一些統計數據。我使用一對舊的ConnectX-2卡和Dell PowerEdge 2970服務器進行測試。 CentOS 7.1和M​​ellanox OFED 3.1版。

我只對延遲測試感興趣。

jVerbs

Test是RPING樣品的變化（可以在github張貼如果任何人的愛好）。通過可靠連接測試下列調用序列的5000000個週期的測量延遲。消息大小是256字節。

PostSendMethod.execute() 
PollCQMethod.execute() 
CompletionChannel.ackCQEvents() 

結果（微秒）：

• 中位數：10.885
• 99.0％百分位數：11.663
• 99.9％百分位數：17.471
• 99.99％百分位數：27.791

JSOR

通過JSOR套接字進行類似的測試。測試是一本教科書客戶端/服務器套接字示例。消息大小也是256字節。

結果（微秒）：

• 中位數：43
• 99.0％百分位數：55
• 99。9％百分位數：61
• 99.99％百分位數：217

這些結果是從OFED延遲測試很遠。在相同的硬件/操作系統標準ib_send_lat基準測試中，生成的中值爲2.77，最大等待時間爲23.25微秒。