延迟加载或不努力提高性能答案

【问题标题】：To Lazy Load or not in effort to improve performance延迟加载或不努力提高性能
【发布时间】：2009-05-18 14:34:57
【问题描述】：

有人建议，为了提高我们系统的性能，应该全面使用延迟加载。也就是将带有“mappedBy”属性的 OneToOne 映射更改为 @OneToMany 映射。这是为了解决和停止从数据库加载不需要的数据，这会导致应用程序运行缓慢。

我们运行一个多层系统（基本上是 2 层）。我们有前端 - 使用 JSF 和包含业务和数据库访问层的后端。前后通信视图 EJB - 但 EJB 在其中没有真正的逻辑。使用的其他技术 - Spring 和 Hibernate

现在，在对该主题进行了一些阅读之后，似乎延迟加载的使用并不是灵丹妙药，因为它需要正确应用。对于每次延迟加载，都会发出一条 Select 语句来获取数据。还有一个问题是，如果前端访问要延迟加载的属性并且会话/连接在后端关闭，那么我们将得到一个空值。

以上问题正确吗？

那么，在实施延迟加载解决方案或性能改进方面，最好的方法/实践是什么？希望尽可能不要重做数据模型。

我最初的想法是与 DBA 小组合作，以了解两个系统之间发生的情况 - 查询的外观、我们如何使用数据等。识别故障点，检查 Hibernate 对象/查询看看如何最好地改进它。还要查看前端以确定数据从后端传递到前端以显示的内容和方式等。

好的方法/其他方法？

【问题讨论】：

【解决方案1】：

您应该做的第一件事是测量您的应用程序并找出导致性能问题的确切原因。

使用 JProfiler 之类的工具找出问题所在。

一旦您知道发生了什么，您就可以决定如何解决它。

在不知道导致性能问题的原因的情况下直接实施延迟加载方案将浪费您的时间。

如果您发现 DB 层是您的问题所在，那么您可以让 DBA 参与进来，看看您的架构/查询是否可以在做任何更激进的事情之前得到改进。

【讨论】：

【解决方案2】：

确实，如果您的数据获取会减慢加载时间，那么延迟加载是一个很好的解决方案。但全面应用它似乎是一个过早的优化。您可能希望为每组数据隐含它，然后测试它是否可以加快应用程序的速度。如果不是，那么它不是延迟加载的好选择。

我实现延迟加载的方式没有导致数据层发生变化。这一切都在业务逻辑和表示控制器中。由于我不熟悉 EJB，因此我假设这适用于您的 java 应用程序。无论如何，当我实现延迟加载时，我不加载任何数据（至少没有我要延迟加载的数据），直到需要它。然后我调用数据层并获取我的数据（或数据子集）。

至于连接问题，您需要进行检查以测试数据连接以查看它是否已关闭。也就是说，您是否正在汇集数据连接。然后，如果连接已关闭，则重新打开它。但与实际的延迟加载实现一样，这应该在您的逻辑类中完成，而不是在前端完成，因此您不必多次重复此功能。

【讨论】：

【解决方案3】：

延迟加载非常适合延迟昂贵的操作，但我同意你的结论，即它不是解决所有性能问题的灵丹妙药。

凭直觉，先做一些分析，看看应用程序中真正的性能问题在哪里。事实证明，延迟加载某些数据将是一个很好的解决方案，或者它可能是完全不同的东西。在您开始分析和分析应用程序内部发生的事情之前，真的没有办法知道。

【讨论】：

【解决方案4】：

这在很大程度上取决于您要做什么，很难说。你去找你的 DBA 的想法肯定会很有成效。人们唯一能做的就是提供一些例子。就我而言：

在以下场景中，延迟加载对我们来说是一个巨大的性能提升。我们有一棵巨大的树，有 15,000 个不同级别的节点。最初我们尝试加载整个树然后渲染它。花了很长时间。我们更改了代码以仅在用户扩展节点时才延迟加载分支。节点扩展需要稍长的时间，但应用程序整体感觉更快。在这种情况下，更改映射是有意义的

现在，如果您仍然需要处理整个树，因为您的业务逻辑需要它，延迟加载不会有太大的不同。在这种情况下，仅更改映射确实没有解决方案，甚至可能更昂贵。

您需要考虑一下您的应用程序在做什么，在哪里感觉很慢，您想要完成什么。拔出分析器也不是灵丹妙药。

如果没有来自您的应用程序的具体示例，那么说延迟加载是否有用是没有意义的。

【讨论】：