3

我对 JSOR 和 jVerbs 都有基本的了解。

两者都处理 JNI 的限制并使用快速路径来减少延迟。它们都使用用户动词 RDMA 接口来避免上下文切换并提供快速路径访问。两者都具有零拷贝传输选项。

不同的是，JSOR 仍然使用 Java Socket 接口。jVerbs 提供了一个新的接口。jVerbs 还有一个叫做 Stateful Verbs Call 的东西来避免 RDMA 请求的重复序列化，他们说这可以减少延迟。jVerbs 提供了更原生的接口，应用程序可以直接使用这些接口。我阅读了 jVerbs SoCC 2013 论文，他们在 jVerbs 之上构建了 jverbsRPC，并表明它显着减少了 zookeeper 和 memcache 操作的延迟。

两者的文档都表明它们比基于 TCP/IP、SDP 和 IPoIB 的常规 Java 套接字执行得更好。

我没有 JSOR 和 jVerbs 之间的任何性能比较。我认为 jVerbs 可能比 JSOR 表现更好。但是，使用 JSOR，我不必更改现有代码，因为它仍然使用相同的 java 套接字接口。我的问题是，相对于 JSOR，使用 jVerbs 的性能增益可能是多少。有没有人知道或有处理这两者的经验？如果您有任何比较数据，那就太好了。我找不到任何东西。

4

2 回答 2

5

以下是使用DiSNI（IBM jVerbs 的新开源继承者）和DaRPC（使用 DiSNI 的低延迟 RPC 库）的一些数字。

  • 64 字节的 DiSNI RDMA 读取延迟低于 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 <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) 发送/接收基准

服务器：

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

在此处输入图像描述

于 2016-08-08T16:20:50.357 回答
1

比较 jVerbs 与 JSOR 的性能有点困难。第一个是面向消息的 API，而第二个将 RDMA 隐藏在 Java 套接字的基于流的 API 后面。

以下是一些统计数据。我使用一对旧的 ConnectX-2 卡和 Dell PowerEdge 2970 服务器进行测试。CentOS 7.1 和 Mellanox OFED 版本 3.1。

我只对延迟测试感兴趣。

动词

测试是 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 微秒的最大延迟。

于 2016-02-24T03:18:22.057 回答