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微秒。