首页 文章

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

提问于
浏览 次
3

我的任务是扩展应用程序的会话 . 从我的研究中，最明显的选择是使用State Server会话提供程序，因为我不需要用户会话来持久化（SQL Server Session提供程序）

关于应用程序：

  • 目前正在使用InProc会话提供程序

  • 会话中存储的所有对象都是可序列化的

  • 所有对象都很小（大多数是简单的对象（int，string）和一些简单的类实例）

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

谢谢！用户反馈：

  • 为什么我们使用会话：回发之间的数据持久性（例如用户选择）

  • 如何：用户进行选择，存储选择 . 用户离开页面并返回，选择将被恢复 . 等等

  • 将创建一个Web场

c# asp.net session architecture asp.net-4.0

4 回答

  • 1
    回复于
  • 5

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

    State Server可以帮助您扩展的地方是，它允许负载 balancer 的Web场中的多台计算机共享单个会话状态 . 但是，它受机器内存的限制，如果您有大量并发会话，则可能需要使用SQL会话状态提供程序 .

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

    Also, here's a link for using Memcached as a Session State provider . 再一次，我没有提出意见......

    编辑：正如@HOCA在评论中提到的那样，如果听说（但未使用）成本是ScaleOut SessionServer，则有第三方解决方案 .

    回复于
  • -1

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

    特别是使用“非常小的对象”时，请使用viewstate . 为什么？

    • 最好的比例 . 没有记住在服务器上 .

    • 不担心会话超时 .

    • 不用担心webfarms .

    • 不用担心永远不会回来的会话浪费资源 .

    特别是在ASP.NET 4中，viewstate可以非常易于管理和小巧 .

    回复于
  • 5

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

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

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

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

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

    在很少的情况下，根据需要从数据库服务器中提取它需要更长的时间或导致更多的流量，而不是从远程会话服务器获取它 .

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

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

    回复于

相关问题