JSF 性能：JSF 的可扩展性如何？
我还没有找到 JSF 性能的良好基准。我知道你在想什么，这取决于你的代码/设计/数据库设置等。我知道在需要优化表示层之前你必须优化很多东西（例如你应该看看你的数据库模式有多好） ，但是为了论证，我们已经到了必须审查表示层的地步。
JSF 是会话密集型的。我已经多次读到，在编写可扩展的应用程序时，这可能是一个缺点。在集群环境中拥有大量用户会话可能会出现问题。有这方面的文章吗？我不愿意投入生产，只是为了看到出色的 JSF 生命周期和 CDI 集成在性能方面付出了巨大的代价。
I have yet to find a good benchmark on JSF performance. I know what you are thinking, it depends on your code/design/database setup, etc. I know that you have to optimize many things before you need to optimize your presentation layer (for instance you should see how good your database schema is), but let's say for the sake of the argument that we have reached the point in which we must review our presentation layer.
JSF is session-intensive. I've read a bunch of times that this can be a drawback when it comes to writing scalable applications. Having big user sessions in a clustered enviroment can be problematic. Is there any article on this? I'd hate to go to production just to see that the great JSF lifecycle and CDI integration have a huge cost in performance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为了获得高性能，无论框架或语言如何，都必须实现会话粘性。如何完成取决于您的设置；例如，硬件负载平衡器通常具有此功能。那么您实际上不必担心服务器间的网络延迟。
不过JSF+CDI在单机上的性能也很重要。假设开销为300ms，这意味着4核服务器每秒只能处理10个请求。还不错，但不属于高性能级别。 （对于 JEE 潮流的公司来说通常不是问题；它们通常是企业规模的，而不是互联网规模的；而且他们有足够的现金来购买大量服务器）
不过，我并没有真正的性能数据；如果有人报告一些 CDI+JSF 统计数据，例如处理具有中等大小表单的典型页面需要多长时间，那将会很有趣。
For high performance, session stickiness must be implemented, regardless of framework or language. How that's done depends on your setup; for example hardware loadbalancers usually have this feature. Then you don't really have to worry about inter-server network latency.
However, JSF+CDI performance on a single machine is also very important. Suppose the overhead is 300ms, that means a 4-core server can only handle 10 requests per second. Not too bad, but not in the high performance class. (Usually not a problem for companies on JEE bandwagons; they are usually enterprise-scaled, not internet-scaled; and they have cash to burn for lots of servers)
I don't really have the performance number though; it would be interesting if someone reports some CDI+JSF stats, for example, how long it takes to handle a typical page with a moderate size form.
我不知道 JSF 大量使用会话数据的说法是否属实。但是，我认为解决由于大量会话数据而导致的可扩展性问题的方法是：
复制前端服务器（超出某个扩展点时您必须这样做），并且
根据会话令牌将请求分派到前端，以便会话数据可能会已在内存中可用。
I don't know if there is any truth in the assertion that JSF is heavy on session data. However, I'd have thought that the way to address scalability issues due to large amounts of session data would be to:
replicate the front-end servers (which you have to do anyway beyond a certain point of scaling), and
dispatch requests to the front-end based on the session token, so that the session data is likely to already be available in memory.
表示层是-> 的一个实例。令人尴尬的并行应用程序。原则上你可以通过添加硬件来扩展它；一种极端的情况是在站点最大用户数的一分钟内为每个用户提供一个超线程。所以可扩展性在这里不是问题。可能出现的问题是页面必须按顺序呈现，即使在单用户模式下也需要很长时间才能呈现：如果您的 JSF 在单用户模式下需要一分钟才能呈现，那么在多用户模式下也会如此模式，如果你不能并行渲染它的多个部分，那么这是普通的必要的。
The presentation layer is one instance of an -> embarrassingly parallel application. In principle you can scale it by adding hardware; an extreme would be to have one hyper-thread per user in the minute of your site's maximum user-count. So scalablilty is not a problem here. What might be a problem is with pages that have to be rendered sequentially and take a long time to render even in single-user mode: If your JSF takes a minute to render in single-user mode then it will so too in multi-user mode and if you can not render it in multiple pieces in parallel then that is plain-old necessary.