JPA + EJB对于互联网交易来说速度太慢或负荷过重了吗？

Question

我正在开发一个独立的Java客户端应用程序，它连接到Glassfish v3应用程序进行JPA/EJB门面风格的事务处理。换句话说，我的客户端应用程序不直接连接数据库进行CRUD操作，而是使用EJB无状态会话传输JPA对象。

我有一些情况下需要在外部网络上使用此客户端应用程序，并通过Internet上的VPN连接，客户端连接速度为512kbp/DSL，简单的查询需要很长时间。我看到流量图表时，当我在客户端应用程序中合并实体时，我看到了大量的流量（我无法相信采购订单实体可能重达1 MB以上）。

我在几乎每个多对多关系中都有懒惰加载，但我有很多实体之间的多对一关系（但这是JPA的巨大优势！）。

我能做些什么来加快JPA/EJB服务器和远程Java客户端之间的交易速度吗？

谢谢您的帮助。

- Xavier Callejas

Answer 1

你真正传输了多少数据？也许你正在发送的采购订单包含一个产品，该产品有一个型号，该型号有一个供应商，该供应商又有一组型号...以此类推...

你可以尝试将要发送到服务器的对象序列化为文件（使用标准的ObjectOutputStrem），并检查文件的大小。

- Guillaume

Answer 2

我看到了流量图表，当我在客户端应用程序中合并实体时，我看到了几兆字节的流量（我无法相信一个采购订单实体会超过1MB的大小）。

RMI-IIOP比普通RMI更冗长。根据我的经验，在传输大型图形时，它的效果不佳。

就我所记得的（但也许这段时间内有所改变），当你传输一个懒加载的实体时，尚未加载的部分会按原样发送（代理被序列化），这意味着如果没有会话，你无法在客户端上访问它们，因为懒加载不起作用。你是否在将实体发送回客户端之前急切地加载它？

我能做些什么来加速JPA/EJB服务器和远程Java客户端之间的交易速度吗？

但问题的关键是，你处于需要考虑数据传输策略的情境中。你必须以一种方式设计你的应用程序，使你不发送大型图形；这个问题必须在你的应用程序设计中得到解决。然后你可以决定仍然发送JPA实体或依赖于数据传输对象（DTO）。

您也可以考虑在有状态会话 Bean 中使用扩展持久性上下文，这样我认为仍然可以懒加载客户端上的实体。但我个人从未使用过，并不知道它是否有效。

- ewernli

Answer 3

如果我正确理解你的架构，你有：

 Client(works with disconnected Entities)  
            ----RMI/IIOP--->
 Server(SLSB, using entitiy manager, JPA persistence) 
            ----JDBC------->
 Database

实际上，您的SLSB是以JPA对象为基础表达其接口，而您的DTO则是JPA对象。我看到了两种可能的情况：

1. 您的客户端仅需要JPA对象中的数据子集，而您正在传输比实际需要更多的数据。例如，您可能只需要员工的姓名，但却发送了他的整个生平历史。
2. 您正在遍历比您想要的关系树更多的内容。

我的感觉是，您应该首先确定客户端获取了什么数据。通过添加一些跟踪语句来查看您拥有的确切数据应该很容易。

通过调整延迟加载等方式，您可以控制行为。

我的期望是，您可能需要定义特定于客户端的“子集”DTO，并使您的SLSB更像一个门面，仅发送子集数据。这更费力，但您可以对接口中的内容进行精细控制。

从架构上讲，微调远程接口是非常合理的需求。

- djna

Answer 4

我能做些什么来加速 JPA/EJB 服务器和远程 Java 客户端之间的事务速度吗？

你无法加速事物。但是，您可以传输更少的数据（仅所需部分或较轻的对象）。

- Pascal Thivent