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

Question

OpenEJB 4.0.0 有一些可用的传输:

ejbd

ejbds

httpejbd

网络上哪一个更轻？

哪个更快？

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

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

更新:

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

更新(2012 年 10 月 8 日):

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

Answer 1

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

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

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

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

我的建议是消除协议(protocol)层导致超时问题的想法。更有可能是客户端的数量，而不是它们是远程的事实。可以执行 @Remote通过从 LocalInitialContextFactory 查找与服务器相同的 VM 中的 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将向您展示您可以从任何远程处理层获得的理论上的最大性能。

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