使用 Session 防止往返请求答案

【问题标题】：Using Session for preventing round trip requests使用 Session 防止往返请求
【发布时间】：2010-11-18 19:28:18
【问题描述】：

我在用户控件中有一个 Telerik 菜单，位于 aspx 页面中，我需要根据登录用户生成菜单。

所以我需要将数据源绑定到菜单。我的网站每天将有 1000 多个用户。为了防止往返请求，我从会话中生成菜单。
为此，我使用 InProc 会话并将 Sql 数据保留在会话中。

菜单的会话对象大小约为 40 字节。所以（1000 个用户）*（40 字节）=大约 40K 服务器的内存。我没有任何其他服务器可以使用 StateServer Session。而且我也会将会话用于其他目的。

有没有更好的解决方案，因为性能在我的场景中起着关键作用。或者我已经选择了最好的解决方案？

【问题讨论】：

1) 每天 1000 个用户还是同时有 1000 个用户？ 2) 到目前为止，我知道菜单是每个用户自定义的，您可能有 1000 个不同的菜单，不是吗？
如果内存使用和请求处理时间不是很重要，我会考虑实现一个 SiteMapProvider (msdn.microsoft.com/en-us/library/…)。如果您可以在其中缓存用户数据，那么整个站点结构可能是特定于用户的。当您需要实施其他导航控件和安全限制时，这可能会有所帮助。
是的 1000 个同时用户，菜单是每个用户自定义的。
我主要关心内存使用和请求处理时间。所以这就是我与你们分享我的场景的原因。

标签： asp.net caching session

【解决方案1】：

听起来您这样做应该没有任何问题，但您可能对my answer to this question 感兴趣。

一般来说，会话是缓存数据的好地方：

比较小，
获取成本高，并且
不需要在给定用户会话之外使用

听起来您至少符合上述前两个要求。

我从事的一个项目的需求与您描述的类似，但许多用户最终会得到完全相同的菜单，而且菜单本身的生成成本很高，所以我将问题分成几部分，像这样：

用户的 PersonId 存储在会话中。
MenuKeyRepository 将获取需要为给定人员 ID 显示的菜单项键的 ID 列表，并将此列表作为“MenuKey”返回。
MenuRepository 会根据给定的 MenuKey 生成实际菜单。

这两个存储库使用了滑动内存缓存，因此在大多数情况下，菜单键和菜单本身都已经构建好了。如果新用户登录，但应该看到与其他最近用户相同的菜单项，则第一个存储库需要构造他们的菜单键，但实际菜单已被缓存。

我不知道这种方法对你是否有意义，但它是值得的。

【讨论】：

每个用户都有多个角色。而且每个页面也有多个角色。我将登录用户的角色与页面的角色相匹配，并为该用户生成自定义菜单。在许多情况下，他们会有相同的菜单。但是不知道什么时候该把重复的自定义菜单放入缓存中。
@arlen：因此，如果您经常拥有具有相同角色集的大量用户，并且如果生成的菜单比角色列表大得多或生成成本更高，您可能会制作一个组合键入用户的角色 ID。然后任何具有相同角色集的人都可以重用相同的生成菜单项。这有意义吗？
@arlen：没错。但是，就像我说的那样，只有当您期望很多用户具有相同的角色时。例如，如果 50% 的用户具有角色 (1,2)，这种方法可能会给您带来更好的性能，因为您不必在每次新用户登录时都将角色 1 和 2 匹配到每个页面。
@arlen：我猜逻辑更像var menu = (Menu)Cache.Get(rolesString); if(menu == null) Cache.Set(rolesString, menu = GenerateMenu(roles));
@StriplingWarrior ：您的意思是如果 user1=roles(1,2,3) 和 user2=roles(1,2,3,4) - 然后我为 keyUser1=123 和 keyUser2 生成复合键=1234 所以如果 keyUser1=keyUser2 从缓存中检索菜单。否则生成新菜单并将新菜单放入缓存 Cache.Insert(keyUser2, "MenuItems")。所以在这种情况下，缓存会占用服务器的内存。因为我会有角色的组合。所以现在我有缓存而不是会话......那么这样做有什么好处呢？我称你的方法为“使用缓存实现 InProc 会话”

【解决方案2】：

假设会话超时不是问题，这看起来已经是一个很好的解决方案了。

【讨论】：

在这种情况下会话的最佳超时值是多少？
这似乎是一个特定于硬件的问题 arlen