会话状态服务器与自定义会话状态提供者

时间:2011-01-14 17:07:53

标签: c# asp.net session architecture asp.net-4.0

我的任务是扩展应用程序的会话。从我的研究中,最明显的选择是使用State Server会话提供程序,因为我不需要用户会话持久化(SQL Server会话提供程序)

关于应用:

  • 目前正在使用InProc会话提供程序
  • 会话中存储的所有对象都是可序列化的
  • 所有对象都很小(大多数是简单的对象(int,string)和一些简单的类实例)

在我首先进入IT方面并且能够使用ASP.NET 4提供自定义会话提供程序之前,我是否应该考虑自定义会话状态提供程序。为什么或者为什么不?那里有“好”的吗?

谢谢!   用户反馈:

  • 为什么我们使用会话:回发之间的数据持久性(例如用户选择)
  • 如何:用户进行选择,存储选择。用户离开页面并返回, 选择恢复。等等。
  • 将创建一个Web场

4 个答案:

答案 0 :(得分:5)

这取决于“缩放”会话存储的含义。如果您只是简单地谈论会话状态性能,那么您将无法击败进程内会话状态提供程序。切换到State Server提供程序实际上会使事情变得更慢 - 由于跨进程边界序列化和传输对象的额外开销。

State Server可以帮助您扩展,它允许负载平衡的Web场中的多台计算机共享单个会话状态。但它受机器内存的限制,如果你有很多并发会话,你可能想要使用SQL Session State提供程序。

为了在Web场中获得最佳性能,您还可以尝试使用之前建议的AppFabric。我自己没有这样做,但它是explained here.

Also, here's a link for using Memcached as a Session State provider。再说一遍,我没有用它,所以我不能对它提出意见......

编辑:正如@HOCA在评论中提到的那样,如果成本不是问题,则有第三方解决方案。我听说过(但未使用过的)是ScaleOut SessionServer

答案 1 :(得分:5)

答案 2 :(得分:1)

我强烈建议您在查看扩展会话之前先评估是否首先需要会话。

对于每个页面加载,会话变量都被序列化和反序列化,无论页面是否使用该数据。 (编辑:Craig指出你对.net 4 http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstatebehavior.aspx有一定程度的控制权。但是,这仍有缺点,请参阅对此答案的评论。)

对于单个服务器实例,这是可以的,因为您只是从Web服务器的本地内存中提取它。这些应用程序的负载往往非常小,因此在本地缓存用户特定信息是有意义的。

但是,只要将会话存储移动到另一台服务器,就会增加应用程序的网络要求和页面加载时间。即,每个页面将导致会话数据从远程服务器,通过网络线路移动到Web服务器的存储器中。

此时您必须问自己:是否需要直接从数据库服务器直接提取此信息,而不是每次从会话服务器中提取此信息?

有一些情况下,根据需要从数据库服务器中提取它需要更长的时间或导致更多的流量,而不是从远程会话服务器中获取它。

请记住,很多人将他们的数据库服务器设置为会话服务器,您开始明白为什么使用会话没有任何意义。

我唯一考虑将会话用于负载均衡的网络应用程序的时间是获取数据的时间超过“合理”的时间。例如,如果您有一个非常复杂的查询来返回单个值,则必须为大量页面运行此查询。但即使这样,也有更好的方法可以降低处理远程会话数据的复杂性。

答案 3 :(得分:-1)

无论提供商是谁,我都会建议不要使用会话状态。

特别是使用“非常小的对象”时,请使用viewstate。为什么呢?

  1. 最好的衡量标准。没有记住在服务器上。
  2. 不用担心会话超时。
  3. 不用担心webfarms。
  4. 不用担心永远不会回来的会话浪费资源。
  5. 特别是在ASP.NET 4中,viewstate可以非常易于管理。