对于 OpenEJB，什么是最高效、最轻量的传输方式？答案

【问题标题】：What is the most performant and lighter transport for OpenEJB?对于 OpenEJB，什么是最高效、最轻量的传输方式？
【发布时间】：2012-08-06 23:00:29
【问题描述】：

有一些可用于 OpenEJB 4.0.0 的传输：

ejbd
ejbds
httpejbd

网络上哪个比较轻？

哪个更快？

选择其中任何一个有什么利弊吗？

我们的应用程序有大约 450 个客户端与 OpenEJB 4.0.0 容器上的远程 EJB 通信。全部在本地 LAN 中（但使用具有一些冗余的级联交换机）。

更新：

这个问题与另一个关于超时的问题无关。我们没有任何可以识别的超时或应用程序问题。当我们的客户端数量有限时，该应用程序运行良好，但当我们尝试使用数百个客户端时，我们面临似乎是网络错误：服务器日志显示重复出现“收到 IoExpcetion 未知字节”。由于据报道 CORBA ORB 存在广播问题，我们怀疑它可能是 RMI over IIOP 类型的问题。我们将尝试其他协议选项来与我们当前的设置进行比较。

更新（2012 年 1 月 8 日）：

我们现在已经运行了数百个测试，一个 LAN 中有 450 多个客户端。没有一刀切的答案。如果我们的客户很少，EJBD 会更快。如果我们有数百个客户端，EJBD 就会停止工作（这似乎会导致开关饱和）。对于数百个客户端，httpejbd 仍然可以工作（这似乎与每个远程调用都会创建一个持续时间短的 http 请求有关）。

【问题讨论】：

标签： performance jakarta-ee openejb transport

【解决方案1】：

带有 Jetty 的 httpejbd 可以为更多的客户（数千个）提供服务，但 ejbd 在 10 秒到数百个范围内的速度明显更快。

从纯粹的性能角度来看，这封电子邮件提供了一些很好的信息：

http://openejb.979440.n4.nabble.com/Remote-client-performance-td987613.html

我将再次声明，您看到的超时与客户端/服务器性能无关。更快的客户端/服务器层实际上会增加服务器中的意外事件并使服务器端锁定问题更加明显。

我的建议是消除协议层导致超时问题的想法。更有可能是客户端的数量，而不是它们是远程的事实。通过从LocalInitialContextFactory 查找它们，可以在与服务器相同的VM 中执行@Remote bean。完成此操作后，您将获得一个遵循远程 EJB 语义但不涉及任何网络管道的客户端引用。

让这个客户端产生 450 个线程，每个线程在一个循环中通过连续的请求访问服务器，并完成常规客户端所做的工作。您会发现，您可以在可能远少于 450 个线程（即 450 个客户端）的情况下达到超时。

以下是您可以调用的所有方法的性能分析。这是同一台机器上的同一个对象：

POJO

245,000 TPS -- 显示为基线（不会比 pojo 调用更快）
http://people.apache.org/~dblevins/pojo-performance.png

@Local

212,000 TPS -- 显示上述内容，加上基本“EJB”支持（拦截器、安全性、事务等）的额外成本
http://people.apache.org/~dblevins/openejb-3.1.4-local-performance.png

@Remote 通过LocalInitialContextFactory，服务器端

112,000 TPS -- 显示以上内容，加上序列化和按值传递远程语义的额外成本
http://people.apache.org/~dblevins/openejb-3.1.4-remote-serverside-performance.png

@Remote 通过RemoteInitialContextFactory，客户端（ejbd）

31,600 TPS -- 显示以上，加上网络层的额外成本
http://people.apache.org/~dblevins/openejb-3.1.4-remote-clientside-performance.png

因此，如果您的直觉告诉您是网络层减慢了速度并导致访问超时，请通过创建一个小型性能测试并使用LocalInitialContextFactory 和RemoteInitialContextFactory 运行它来验证该假设。 LocalInitialContextFactory 将向您展示您可以从任何远程处理层获得的理论上的最大性能。

如果问题消失，那么您是对的，您可以继续努力调整网络层。如果问题仍然存在或变得更糟，那么您知道问题不在网络层，您需要改变重点才能取得进展。

【讨论】：

这是我们面临的另一个问题，与超时无关（至少直接）（现在已解决，我们现在没有任何超时）。服务器日志显示很多 I/O 异常，例如“收到意外字节”。此外，一些客户端在没有服务器响应的情况下卡住了，一些客户端不断重复错误，说他们没有经过身份验证。我们知道，如果不是所有这些错误，大多数都是虚假的（我们推测它们与网络相关），因为相同的架构可以完美地与一小部分客户端配合使用。由于我们听说过 CORBA 广播问题，因此我们对 RMI-IIOP 感到好奇。
在我们的网络中进行所有调整后，我们的实验证实了这个答案（我们可以使用 httpejbd 处理比使用普通 ejbd 更多的客户端）。

【解决方案2】：

我没有使用过这两种协议中的任何一种，但我相信通用视图可以帮助您入门，因为我没有在 Internet 上看到这 3 种协议的性能比较。我相信基本的本机和低级实现大多数时候都比高级协议快。在这种情况下，ejbds 的性能不如 ejbd，因为存在 SSL 握手开销。我也相信 ejbds 的性能不如 httpejbd。

【讨论】：