RDMA（JSOR）上的Java套接字与Infiniband中的jVerbs性能
我对JSOR和jVerbs都有基本的了解。
两者都处理JNI的限制并使用快速路径来减少延迟。 它们都使用用户动词RDMA接口来避免上下文切换并提供快速路径访问。 两者都有零拷贝传输选项。
不同之处在于JSOR仍然使用Java Socket接口。 jVerbs提供了一个新的界面。 jVerbs还有一个名为Stateful Verbs Call的东西，以避免重复序列化RDMA请求，他们说这可以减少延迟。 jVerbs提供了更原生的接口，应用程序可以直接使用这些接口。 我阅读了jVerbs SoCC 2013论文，他们在jVerbs上构建了jverbsRPC，并certificate它可以显着减少zookeeper和memcache操作的延迟。
两者的文档都表明它们的性能优于基于TCP / IP，SDP和IPoIB的常规Java套接字。
我在JSOR和jVerbs之间没有任何性能比较。 我认为jVerbs可能比JSOR表现更好。 但是，使用JSOR，我不必更改现有代码，因为它仍然使用相同的Java套接字接口。 我的问题是使用jVerbs相对于JSOR可能带来的性能提升。 有没有人知道或有经验处理这两个？ 如果你有任何比较数据会很棒。 我找不到任何东西。
下面是使用DiSNI （IBM的jVerbs的新开源inheritance者）和使用DiSNI的低延迟RPC库DaRPC的一些数字。
- DiSNI RDMA读取延迟为64字节低于2微秒
- 64字节（请求和响应）的DaRPC RDMA发送/接收延迟大约为5微秒
- 对于单侧操作，Java / 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 -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 -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 -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 -k 1000000 -l 64 -r 64 -b 1
比较jVerbs vs JSOR的性能有点难。 第一个是面向消息的API，而第二个是在Java套接字的基于流的API后面隐藏RDMA。
这是一些统计数据。 我的测试使用了一对旧的ConnectX-2卡和Dell PowerEdge 2970服务器。 CentOS 7.1和Mellanox OFED 3.1版。
我只对延迟测试感兴趣。
jVerbs
测试是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套接字的测试。 Test是一本教科书客户端/服务器套接字示例。 消息大小也是256字节。
结果（微秒）：
- 中位数：43
- 99.0％百分位数：55
- 99.9％百分位数：61
- 99.99％百分位数：217
这些结果与OFED延迟测试相差甚远。 在相同的硬件/操作系统标准上，ib_send_lat基准测试产生2.77作为中位数，23.25微秒作为最大延迟。