我对 JSOR 和 jVerbs 有基本的了解。
两者都处理 JNI 的限制并使用快速路径来减少延迟。它们都使用用户 Verbs 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 套接字接口。我的问题是使用 jVerbs 相对于 JSOR 的性能增益是多少。有谁知道或有处理这两者的经验吗?如果你有任何比较数据那就太好了。我找不到任何。
这是一些使用的数字DiSNI——IBM jVerbs 新开源的后继者——以及DaRPC,使用 DiSNI 的低延迟 RPC 库。
- 64 字节的 DiSNI RDMA 读取延迟低于 2 微秒
- 64 字节(请求和响应)的 DaRPC RDMA 发送/接收延迟约为 5 微秒
- Java/DiSNI 和 C 原生 RDMA 之间的差异对于单方面操作可以忽略不计
这些基准测试已在使用 Mellanox ConnectX-3 网络接口连接的两台主机上执行。
以下是执行基准测试的命令:
(1) 读取基准
Server:
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
Client:
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) 发送/接收基准
Server:
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
Client:
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
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)