OpenEJB 4.0.0有几种传输方式：
哪一个在网络上更轻？
哪一个更快？
选择任何一个是否有任何利弊？
我们的应用程序约有450个客户端在OpenEJB 4.0.0容器上与远程EJB通信。全部在本地LAN中（但使用具有一定冗余的级联交换机）。
更新
这个问题与另一个关于超时的问题无关。我们没有任何超时或应用程序问题，我们可以识别。当我们拥有有限数量的客户端时，该应用程序运行良好，但是当我们尝试使用数百个客户端时，我们面临的似乎是网络错误：服务器日志显示重复出现的“IoExpcetion unkown byte received”。由于据报道CORBA ORB有广播问题，我们怀疑它可能是一个RMI而不是IIOP的问题。我们将尝试其他协议选项来与我们当前的设置进行比较。
更新（2012-oct-08）：
我们现在已经运行了数百个测试，在局域网中有450多个客户端。没有一个尺寸适合所有答案。如果我们的客户端很少，那么EJBD会更快。如果我们有数百个客户端，EJBD会停止工作（它似乎会导致交换机饱和）。有数百个客户端，httpejbd仍然可以工作（这似乎与每个远程调用创建一个短持续时间的http请求有关。）
答案 0 :(得分：3)
从纯粹的绩效角度来看，这封电子邮件有一些很好的信息：
我将再次声明您看到的超时与客户端/服务器性能无关。更快的客户端/服务器层实际上会增加服务器中的意外事件，并使服务器端锁定问题更加明显。
我建议的是消除它是导致超时问题的协议层的想法。它更可能是客户的数量，而不是它们是远程的事实。通过从@Remote查找它们，可以在与服务器相同的VM中执行LocalInitialContextFactory个bean。完成此操作后，您将获得一个遵循远程EJB语义的客户端引用，但不涉及任何网络管道。
让这个客户端产生450个线程，每个线程并在循环中连续请求命中服务器并执行常规客户端的工作。你会发现你可以通过远远少于450个线程（即450个客户端）来达到超时。
以下是您可以调用的所有方法的性能分析。这是同一台机器上的同一个对象：
POJO
@Local
@Remote来自LocalInitialContextFactory，服务器端
@Remote通过RemoteInitialContextFactory，客户端（ejbd）
因此，如果您的直觉告诉您网络层减慢速度并导致访问超时，请通过创建小型性能测试来验证该假设，并使用LocalInitialContextFactory和{{1}运行它}}。 RemoteInitialContextFactory将显示您可以从任何远程处理层获得的理论最大性能。
如果问题消失了，那你就是对的，你可以继续努力调整网络层。如果问题仍然存在或变得更糟，那么您就知道问题不在于网络层，您需要更改焦点才能取得进展。
答案 1 :(得分：0)
我没有使用这些协议中的任何一个，但我相信通用视图可以帮助您入门，因为我没有看到这些3在互联网上的性能比较。我相信基本的本机和低级实现大多数时候比更高级别的协议更快。在这种情况下，ejbds的性能低于ejbd，因为存在SSL握手开销。我也相信ejbds的性能不如httpejbd。
