2

OpenEJB 4.0.0 有一些可用的传输：

  1. ejbd
  2. ejbds
  3. httpejbd

网络上哪一个更轻？

哪个更快？

选择其中任何一个有什么优点和缺点吗？

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

更新：

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

更新（2012 年 10 月 8 日）：

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

4

2 回答 2

3

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

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

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

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

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

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

POJO

@Local

@Remote通过LocalInitialContextFactory，服务器端

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

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

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

于 2012-08-10T22:20:58.017 回答
0

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

于 2012-08-09T17:16:09.483 回答