WebSphere 应用服务器 EJB 优化
我们正在致力于开发基于 Java EE 的应用程序。我们的应用程序与 Java 1.5 兼容，并将通过 EBJ 3.0 和 Web 服务功能包部署到 WAS ND 6.1.0.21。目前的配置是一个单元有两个集群。每个集群将有两个节点。
我们的应用程序，或者我们的系统，正如我更应该说的那样，由两到三个部分组成。
第 1 部分：部署到一个集群的 Ear，其中包含第 3 方供应商代码和自定义代码。他们的代码符合 EJB 2.0 标准，并且有很多 Remote Home 接口。
第 2 部分：一只耳朵部署到与第一只耳朵相同的集群。该ear包含EBJ 3，它调用供应商提供的EJB 2和自定义代码。这些 EJB 3 由同样与 EAR 一起打包的 JSF UI 使用，其中一些还作为 Web 服务（符合 SOAP 1.2 的 JAX-WS 2.0）公开给其他客户端。
第 3 部分：可能还有其他不依赖于我们的供应商/自定义代码应用程序的服务。这些服务将是部署到其他集群的 EJB 3.0 和 Web 服务。
根据现场一些 IBM 工作人员的建议，集群中节点之间的通信可以使用 EJB RMI。但如果我们要跨越集群和/或其他单元，那么通信应该是 Web 服务。
也就是说，我们中的一些人想知道性能和优化通信以提高将使用我们的 Web 服务和 EJB 的应用程序的速度。现在大多数 EJB 都暴露为远程的。 （我们的供应商就是这样设置的，而不是同时暴露本地家庭接口）。我们想知道 WAS 是否在同一节点/集群节点空间中的应用程序之间进行了任何优化。如果两个应用程序安装在同一区域，并且它们通过远程 Home 界面相互调用，那么 WAS 是否足够智能，可以使其成为本地 Home 界面调用？
他们还有其他优化技术吗？我们应该考虑他们吗？我们不应该吗？成本/收益是多少？以下是我们的一位团队成员在电子邮件中发送的问题：
问题是： 假设我们将 EJB 开发为远程 EJB，其中我们的 UI 控制器代码通过 EJB3 与我们的 EXT java 服务通信...我们的选择是什么当EJB服务器和客户端都在同一个容器中运行时进行性能优化？
作为参考，google 给了我一些 2000 年的 ooooooold websphere 性能调优文档，其中解释了一种调优配置，当它们位于同一应用程序服务器 JVM 中时，您可以设置为启用 EJB 通信的“按引用调用”。它指出以下内容：
由于 EJB 本质上是与位置无关的，因此它们使用远程编程 模型。方法参数和返回值通过 RMI-IIOP 序列化并返回 按价值。这是内在的 RMI“按值调用”模型。
WebSphere 为运行 EJB 提供“无本地副本”性能优化 和客户端（通常是 servlet）位于同一应用程序服务器 JVM 中。 “没有本地 副本”选项使用“按引用调用”，并且不会为被调用者创建本地代理 当客户端和远程对象位于同一进程中时。取决于 根据您的工作负载，这可以节省大量开销。
通过添加以下两个命令行参数来配置“无本地副本” 应用程序服务器 JVM：
* -Djavax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.Util
* -Dcom.ibm.CORBA.iiop.noLocalCopies=true
注意：“无本地副本”配置选项可通过以下方式提高性能： 将同一 JVM 中的客户端和 EJB 的“按值调用”更改为“按引用调用”。 这样做的一个副作用是 Java 对象派生（非原始）方法参数 实际上可以通过调用的企业 bean 进行更改。考虑图 16a：
此外，我们将来还将使用 Process Server 6.2 和 WESB 6.2。有什么想法吗？建议？
谢谢
We are working on developing a Java EE based application. Our application is Java 1.5 compatible and will be deployed to WAS ND 6.1.0.21 with EBJ 3.0 and Web Services feature packs. The configuration is currently one cell with two clusters. Each cluster will have two nodes.
Our application, or our system, as I should rather say, comes in two or three parts.
Part 1: An ear deployed to one cluster that contains 3rd party vendor code combined with customization code. Their code is EJB 2.0 compliant and has a lot of Remote Home interfaces.
Part 2: An ear deployed to the same cluster as the first ear. This ear contains EBJ 3's that make calls into the EJB 2's supplied by the vendor and the custom code. These EJB 3's are used by the JSF UI also packaged with the EAR, and some of them are also exposed as web services (JAX-WS 2.0 with SOAP 1.2 compliance) for other clients.
Part 3: There may be other services that do not depend on our vendor/custom code app. These services will be EJB 3.0's and web services that are deployed to the other cluster.
Per a recommendation from some IBM staff on site here, communication between nodes in a cluster can be EJB RMI. But if we are going across clusters and/or other cells, then the communication should be web services.
That said, some of us are wondering about performance and optimizing communication for speed of our applications that will use our web services and EJB's. Right now most EJB's are exposed as remote. (and our vendor set theirs up that way, rather than also exposing local home interfaces). We are wondering if WAS does any optimizations between apps in the same node/cluster node space. If two apps are installed in the same area and they call each other via remote home interface, is WAS smart enough to make it a local home interface call?
Are their other optimization techniques? Should we consider them? Should we not? What are the costs/benefits? Here is the question from one of our team members as sent in their email:
The question is: Supposing we develop our EJBs as remote EJBs, where our UI controller code is talking to our EXT java services via EJB3...what are our options for performance optimization when both the EJB server and client are running in the same container?
As one point of reference, google has given me some oooooold websphere performance tuning documentation from 2000 that explains a tuning configuration you can set to enable Call By Reference for EJB communication when they're in the same application server JVM. It states the following:
Because EJBs are inherently location independent, they use a remote programming
model. Method parameters and return values are serialized over RMI-IIOP and returned
by value. This is the intrinsic RMI "Call By Value" model.
WebSphere provides the "No Local Copies" performance optimization for running EJBs
and clients (typically servlets) in the same application server JVM. The "No Local
Copies" option uses "Call By Reference" and does not create local proxies for called
objects when both the client and the remote object are in the same process. Depending
on your workload, this can result in a significant overhead savings.
Configure "No Local Copies" by adding the following two command line parameters to
the application server JVM:
* -Djavax.rmi.CORBA.UtilClass=com.ibm.CORBA.iiop.Util
* -Dcom.ibm.CORBA.iiop.noLocalCopies=true
CAUTION: The "No Local Copies" configuration option improves performance by
changing "Call By Value" to "Call By Reference" for clients and EJBs in the same JVM.
One side effect of this is that the Java object derived (non-primitive) method parameters
can actually be changed by the called enterprise bean. Consider Figure 16a:
Also, we will also be using Process Server 6.2 and WESB 6.2 as well in the future. Any ideas? recommendations?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
真正可以对远程 EJB 进行的唯一自动优化是它们是否位于同一位置（从同一 JVM 内访问）。在这种情况下，ORB 将缩短某些在请求需要通过网络传输时所需的工作。仍然会有一些必要的 ORB 开销，包括对象序列化（除非您打开 noLocalCopies，以及它带来的所有警告）。
或者，如果您知道 UI 控制器是共置的，您的方法调用不依赖于参数或返回值复制，并且您的接口不依赖于本地视图和远程视图之间的异常差异，那么您可以创建并公开本地子接口这将比通过 ORB 进行远程访问快得多。
The only automatic optimization that can really be done for remote EJBs is if they are colocated (accessed from within the same JVM). In that case, the ORB will short-circuit some of the work that would otherwise be required if the request needed to go across the wire. There will still be some necessary ORB overhead including object serialization (unless you turn on noLocalCopies, with all the caveats it brings).
Alternatively, if you know that the UI controller is colocated, your method calls do not rely on parameter or return value copying, and your interface does not rely on the exception differences between local and remote views, then you could create and expose a local subinterface that will be much faster than remote access through the ORB.