范围和实体类

Question

我是 JSF 和 EE 的新手，并试图了解为项目做出正确设计决策的最佳方法。我正在独自工作，20 多年后重新学习并追求一个非常雄心勃勃的商业理念。

我的问题与我所做的设计选择对系统开销和性能影响有关。我正在使用所有最新版本的 EE7、JSF 2.2.6、NetBeans 7.4、Glassfish 等。如果我没有最新版本，我会随时升级。

我猜这是一个相当大的问题，因为它涉及到 Web 容器范围、ejb 类型和 EM 与 EMF 的完整路径。我读了很多书，相信我理解其中的哲学，但可能并不完全。

我的应用涉及（希望 1,000-100,000+）同时登录的用户，这些用户将连接 4-6 小时，但每 10 分钟左右才发出请求。一开始，它可能只有 100 个左右，我的短期目标是让一些东西发挥作用并从那里改进。然而，我更愿意提前做出正确的决定。

根据我的阅读，我的理解是大多数人会使用 @SessionScoped 支持 bean（当用户登录时）、@Stateless Managed Beans 和可能是容器管理的实体管理器。

虽然这似乎是最容易编程的，但我的解释是开销会很大： - 我将拥有与连接用户一样多的会话范围实例； - 与我拥有的用户一样多的无状态 EJB，因为它们是由 SessionScoped bean 注入的 - 实体管理器中有一个海量缓存，因为每个用户对数据都有不同的兴趣。 - 我还假设 web 和 ejb 会话等于 java 线程，而不仅仅是一些存储的数据。

这样理解接近吗？

虽然要复杂得多，但我认为性能更好的系统将涉及我自己的会话控制、请求范围 bean、无状态 ejb 和应用程序管理实体管理器 (emf)，其中我只在缓存是长期事务时保留缓存。这将创建一个具有较少实例的池化环境，从而减少线程、交换、磁盘缓存等。

我已经大量阅读，使用大量 BalusC 建议构建了一个测试环境，并且从 JSF 生命周期开始对大多数事情都有合理但理论上的理解。尽管 JSF 和 EE 平台似乎是一个不错的决定，但学习曲线有点难以应付。

任何能指出我正确方向的澄清将不胜感激。

提前致谢， 约翰

Answer 1

这样理解接近吗？

部分。

我将有尽可能多的会话范围 我已经连接了用户的实例；

是的，这是正确的。但是这个数字是“虚拟的”，因为容器可以在 LRU 算法和阈值上将其中一些序列化到磁盘（准确地说，整个会话被序列化）。

和我一样多的无状态 EJB 拥有用户，因为他们是由 SessionScoped bean 注入的

这取决于容器的实现。可以合理地说，他们以最有效的方式实施了这种机制。最坏的情况是# of SessionScoped bean (injected EJB) = # of EJB = # of user。

一个 实体管理器中的大量缓存，因为每个用户都有不同的 对数据的兴趣。

缓存是可配置的，但 IMO 你应该考虑缓存大小（添加更多 RAM？）和性能（如果没有缓存怎么办？如果缓存包含每个实体怎么办？）

我还假设 web 和 ejb 会话等于 java 线程，而不仅仅是一些存储的数据。

不，EJB（无状态、有状态和单例）只是数据。 Scheduled one 和 MDB 更类似于您的想法（它们不是线程，而是由执行程序创建一个线程来调用它们）。

虽然要复杂得多，但我认为性能更好的系统将涉及我自己的会话控制、请求范围 bean、无状态 ejb 和应用程序管理实体管理器 (emf)，其中我只在缓存是长期事务时保留缓存。

这取决于您如何配置应用程序服务器、持久性提供程序以及您如何开发业务逻辑控制器 bean。但是，此列表中的每个点都可以在以后进行配置/优化（重构控制器的工作量不大）。

这将创建一个具有较少实例的池化环境，从而减少线程、交换、磁盘缓存等。

EE 堆栈正是这种观点。线程被池化和重用，它们不是特定于用户的，而是特定于请求的。 10 个线程池可以合理地为 100 多个用户提供服务。

我已经大量阅读，使用大量 BalusC 建议构建了一个测试环境，并且从 JSF 生命周期开始对大多数事情都有合理但理论上的理解。尽管 JSF 和 EE 平台似乎是一个不错的决定，但学习曲线有点难以应付。

从您的问题来看，很明显学习曲线对您来说并没有那么难以承受:)

虽然 EE 堆栈与其他技术相比确实很重，但它具有可扩展性、灵活性和可扩展性。和你一样，我认为这是一个不错的选择。

---

根据我的经验，影响性能的最糟糕的事情是网络速度和流量。在某些情况下，我发现加载主页中心图像比执行包含数千行的复杂报告要花费更多时间。

不过，不要（过多）担心优化，因为premature optimization is the root of all evil