我是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的平台似乎是一个很好的决定，但学习曲线有点压倒性。
任何澄清指出我正确的方向将不胜感激。
提前致谢， 约翰
答案 0 :(得分：3)
这是否明白？
部分
是的，这是正确的。但是这个数字是“虚拟的”，因为容器可以在LRU算法和阈值上将其中一些序列化为磁盘（确切地说，整个会话被序列化）。我将拥有尽可能多的会话作用域 我连接用户的实例;
和我一样多的无状态EJB 有用户，因为它们是由SessionScoped bean注入的
它取决于容器实现。可以合理地说，他们以最有效的方式实施这种机制。最糟糕的情况是#SessionScoped bean（注入EJB）=＃of EJB =＃of user。
一个 实体管理器中的大量缓存，因为每个用户都有不同的缓存 对数据的兴趣。
缓存是可配置的，但IMO你应该考虑缓存大小（添加更多RAM？）和性能之间的权衡（如果没有缓存怎么办？如果缓存包含每个实体怎么办？）
不，EJB（无状态，有状态和单例）只是数据。预定的一个和MDB更类似于你的想法（它们不是线程，但是一个线程由执行者创建来调用它们）。我还假设web和ejb会话等于 java线程而不仅仅是一些存储的数据。
虽然要复杂得多，但我认为性能更好的系统会涉及我自己的会话控制，请求范围bean，无状态ejb和应用程序管理实体管理器（emf），其中我只保留缓存，因为它是一个长期的事务。
这取决于您如何配置应用程序服务器，持久性提供程序以及如何开发业务逻辑控制器bean。但是，此列表中的每个点都可以在以后配置/优化（重构控制器的工作量更少）。
这将创建一个池化环境，其中包含更少的实例，因此线程，交换，光盘缓存等等。
EE堆栈正是这种观点。线程被池化并重用，它们不是特定于用户的，而是特定于请求的。 10个线程的池可以合理地为100多个用户提供服务。
我已经大量阅读，使用大量BalusC建议构建了一个测试环境，并且对JSF生命周期中的大多数事情有一个合理但理论上的理解。尽管JSF和EE的平台似乎是一个很好的决定，但学习曲线有点压倒性。
从你的要求中可以清楚地看出，学习曲线对你来说并不那么令人难以忍受：）
尽管EE堆栈与其他技术相比确实很重，但它具有可扩展性，灵活性和可扩展性。像你一样，我认为这是一个不错的选择。根据我的经验，影响性能的最糟糕的事情是网络速度和流量。在某些情况下，我看到加载主页中央图像比执行包含数千行的复杂报告花费的时间要多得多。
但是，不要担心（太多）优化问题，因为premature optimization is the root of all evil