有多少会话数据太多?

这完全取决于通常存在的会话数量(这反过来又取决于您有多少用户、他们在站点上停留的时间以及会话超时)和您的服务器有多少RAM。

但首先:您是否真的使用了内存分析器来告诉您“高内存使用率”是由会话数据引起的,或者您只是在猜测?

但是,在会话中缓存整个结果集也是不好的,原因也不同:如果数据库中的数据发生了更改,并且用户希望看到该更改,该怎么办?如果要缓存,请使用 one of the existing systems

如果您在会话中存储数据以提高性能,则考虑使用真正的缓存,因为缓存是应用程序范围的,而会话是每个用户的,这会导致其他类似对象的无需重复。

但是,如果您要存储它们以供用户编辑这些对象(我对此表示怀疑,因为数百个对象太多了),请尝试最小化存储的数据量或研究乐观并发控制。

我想说,这在很大程度上取决于您期望的活动会话的数量。如果您正在使用<编写内部网应用程序;20个用户,在会话中放入几MB当然没有问题。然而,如果您期望5000个实时会话,那么每个会话存储的每MB数据占5GB的RAM。

然而,我通常建议不要在会话中存储来自DB的任何数据。只需从数据库中获取每个请求。如果性能有问题,请使用应用程序范围的缓存(例如Hibernate的二级缓存)。

什么 友善的 数据量是多少?是每个会话都需要它,还是可以在应用程序级别缓存它?您真的需要所有列还是只需要一个子集?多久访问一次?它需要在哪些页面上可用?等等

我想说的是,尽量存储足够的最小数据量,以便在后续请求中重新创建必要的环境。如果您存储在内存中以避免数据库往返,那么像Memcache这样的真正的缓存解决方案可能会有所帮助。

如果您将这些会话存储在内存中而不是数据库中,则会保存往返过程,并且只要内存负载较低,并且没有分页,请求的处理速度就会更快。一旦客户机数量增加,分页开始,大多数客户机的响应时间就会大幅下降。这两个变量是负相关的。

最好测量数据库服务器的延迟,在大多数情况下,延迟通常足够低,可以被视为一种可行的存储方式,而不是内存。

您还可以创建每个用户的迷你sqlite数据库并连接到它,将用户正在访问的数据存储在其中,然后在用户请求时从中检索记录,在用户断开连接后删除sqlite数据库。