performance - OpenEJB 性能最高、最轻量的传输是什么？

Question

OpenEJB 4.0.0 有几种可用的传输:

1. ejbd
2. ejbds
3. httpejbd

网络上哪一个比较轻？

哪个更快？

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

我们的应用程序有大约 450 个客户端与 OpenEJB 4.0.0 容器上的远程 EJB 进行通信。全部位于本地 LAN 中(但使用具有一定冗余的级联交换机)。

更新:

这个问题与另一个关于超时的问题无关。我们没有发现任何超时或应用程序问题。当我们的客户端数量有限时，该应用程序运行得很好，但是当我们尝试使用数百个客户端时，我们会遇到似乎是网络错误的情况:服务器日志显示反复出现的“IoExpcetion unkown byte returned”。由于据报告 CORBA ORB 存在广播问题，我们怀疑这可能是 IIOP 上的 RMI 类型的问题。我们将尝试其他协议(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)层导致超时问题的想法。更可能的是客户的数量，而不是他们位于远程的事实。通过从 LocalInitialContextFactory 查找@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 将向您展示任何远程处理层所期望的理论最大性能。

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