【问题标题】:JSP session memory?JSP 会话内存?
【发布时间】:2010-12-07 20:09:06
【问题描述】:

我需要确认一个理论。我正在学习 JSP/Java。

查看现有应用程序(不是我写的)后,我注意到我认为导致我们的性能问题的一些东西。或者至少是其中的一部分。

它是这样工作的:

1) 用户打开搜索页面。

2) 搜索页面(默认情况下)会显示所有行。其中 329,000 人。是的。 329K。进入一个 ArrayList。 ArrayList 中的每一项都是绑定到 DB 表的自定义 JavaBean。

3) 然后将 ArrayList 传递给 PaginateResultSet。

4) PaginateResultSet (prs)(329k 行)然后存储在会话变量中: session.setAttribute("resultSet", prs);

5) 每个额外的“下一页”然后从 getAttribute("resultSet") 中获取 20 行并发送到 Ext 数据网格。

好的,现在,我认为每个用户的每个线程都将巨大的结果集存储在服务器的内存中是错误的吗?因此,如果该结果集占用 20 megs 的内存,并且我们有 20 个并发用户,那么我们现在有 400 megs 从服务器获取?

在会话属性中传递这么多数据不是一个坏主意吗?

感谢您的任何指点。

【问题讨论】:

    标签: jsp performance session-variables


    【解决方案1】:

    肯定将整个 DB 表内容复制到 Java 的内存中是个坏主意,更不用说在多用户环境中的用户会话中了。

    您需要在数据库级别进行分页并将感兴趣的行存储在请求范围内。具体如何执行取决于 DB 接口和使用的 DB。如果您使用的是基本 JDBC,您可能会发现 this answer 很有用。对于核心 Hibernate 或 JPA,请参阅 this answer

    【讨论】:

    • 谢谢。我也是这么想的。他们正在使用 Hibernate,但我不确定到什么级别。那 329k 行正在快速增长。上周是270,000。所以当我们发展到更多用户时,这种方法真的开始失效了。
    • 是的,他们肯定在 SESSION 级别进行分页。您认为这会导致 Tomcat 也停止响应吗?
    • 当然有这么多记录。 Google 也不会为每个唯一用户将数据库中的无数行复制到 Java 内存中。仅仅一两次访问它就已经死了。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-12-02
    • 1970-01-01
    • 1970-01-01
    • 2014-10-17
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多