我最近接手了一个支持项目，其中一个Web应用程序在使用数据加载页面方面表现非常糟糕。经过故障排除后，我发现它从数据库中提取的记录数为8541，并存储在名为originalList的列表中。然后根据特定条件过滤列表，并将其存储在名为filteredList的列表中，计数为2170.这两个列表都存储在会话对象中。然后屏幕上会显示filteredList。对于整个过程，它需要花费一分多钟时间，因此有时会超时（请注意代理服务器上的最大超时设置为1分钟，我们无法更改）。这种情况发生在屏幕的加载过程中，无需人工干预。
在会话中存储两个列表的原因是：屏幕还有一些搜索条件，用户填写某些搜索框并单击搜索按钮。系统正在尝试根据搜索条件从名为originalList的列表中过滤数据，而不是从数据库中获取数据。这是由用户触发的。
问题：
使用的技术：
由于它以非常古老的方式开发，我无法改变框架。
答案 0 :(得分：0)
建议在会话中存储大量数据吗？
没有。您正在会话中存储10K（8000 + 2000）条记录。会话是每个用户。如果您有1000个用户，则在内存中存储1百万条记录。你有多少RAM？而BTW，即使有无限量的RAM，也是一种浪费，它不需要，它没有附加价值......这是错误的。
为什么在屏幕上加载~2000条记录需要花费超过一分钟的时间？
我们应该看到你的代码，但考虑到如何处理会话事件，可能还有其他罪魁祸首......它可能是任何地方，任何地方。启用devMode，调试日志，尝试查找瓶颈所在。
会话中的大量数据是否会影响屏幕上加载的数据？
可能。
在用户触发搜索时，是否可以更改设计以从数据库获取数据而不是从会话中访问？
<强>绝。
您或编写该软件的人不知道（或者已经无法解释地避免）解决此问题的最简单方法： PAGINATION 。
如果使用普通JDBC，则更容易。
你有8000条记录，（或800万条记录，它并不重要）：不是加载所有记录，而是应用过滤和排序，你
然后你创建一个查询，说你想要一个PAGE_SIZE记录数，从PAGE * PAGE_SIZE开始，过滤器是从CRITERIA获取的，ORDER是由排序参数获取的。
Here is how to do it with SQL Server
您将始终点击数据库，但只能取出20-50-100条记录，而不是8000条记录.RAM将始终是免费的，List将是一个小而且页面将加载少于1- 2秒。
PS：正如Scary Wombat所建议的，如果你有少量记录（8000很小）和大量访问，你可以考虑在Singleton中缓存列表（所以不在会话中，每个用户一次，但是在一个集中的对象中。由于你必须处理数据刷新，同步等等，它会带来更多的复杂性......所以在这种情况下，我只是选择分页。
注意：无需更改框架，但我绝对会考虑迁移到最新版本的 Struts 2.3.x 。也许需要进行一些调整，但是你会在安全性和性能方面获得很多（取决于你现在的版本）。