普通香草.NET Web服务应用程序中HTTP会话状态的替代方法

问题描述

|| 在与ASP.NET中的页面生命周期及其性能进行了长期斗争之后，我们开始重构我们的Web应用程序以在客户端上实现Web服务（纯香草.asmx .NET Web服务）和jQuery。注意：这不会以任何方式实现MVC或ASP.NET，这些仅仅是Web服务。 在应用程序的两个发行版中，我们都在一个页面中动态生成所有内容。在ASP.NET分配中，这意味着（由于“页面生命周期”）（整个页面需要被拆除），并且（几乎）每个AJAX调用或更改为Web表单都需要重建整个页面。这为旨在为许多并发用户提供服务的应用程序带来了巨大的可扩展性问题。在Web服务/ jQuery分发中，我们可以选择性地仅关注DOM中需要向服务器发送或接收数据的那些元素，这意味着更少的请求和更快的用户体验。 该应用程序的第一次迭代显示性能提高了一个数量级。但是，随着我们开始构建越来越多的Web服务，该应用程序的性能现在与ASP.NET发行版的性能相当。 经过大量的Google搜索/灵魂搜索和负载测试之后，很明显HTTP会话是罪魁祸首。从本质上讲，每次读取（有时仅通过将Session包含在Web服务方法范围内）都是一个阻塞调用，它会带来500ms的延迟。一旦知道了要看的地方，就会在MSDN文献中有很好的记录。按照实现，Session（如果同一用户被多个Web服务使用）将异步请求转换为具有500ms缓冲区的同步请求。当前，我们通过将所有AJAX调用彼此链接为“成功”事件来缓解这种情况，使它们同步来自客户端的请求。这消除了由于请求对锁定的Session对象进行读取而导致的500ms延迟。 使客户端应用程序以“同步”方式运行已经解决了许多性能问题。但是，这只是短期的权宜之计。 有哪些可行的（可扩展！）Session替代方案，再次记住我们不在ASP.NET或MVC或WCF等上？我们最大的障碍是元数据集合的持久性，该集合将在登录时为每个用户初始化。这是应用程序中最昂贵的一项操作（大约10倍或更多），而我们只想执行一次。 Session提供了一种简单的方法，可以让您一次流汗，永不回头。但是这种方法看起来不太可行。 一种方法可能是消除单一的元数据收集神类，并将这种一神论类发展为半神半神的多神论集合。可以以较低的成本更频繁地安装半神人。可行，但需要大量重构，大量开发和质量检查时间。另一个候选人只是将所有状态信息存储在数据库中，但这有其自身的成本-延迟并不是最不重要的。 对于此问题是否还有其他解决方案，可能需要较少的精力来实施？     

解决方法

解决您的问题真的很容易。 在整个网站的web.config中关闭会话 在sql server中创建表： 创建表Session （      SessionId int（或GUID）      ...      ... ） 创建具有外键回到会话表（带有删除级联）并存储会话特定信息的单独表 在应用程序方面，可以将SessionId存储在cookie或查询字符串中。然后，您可以按需查找所有会话信息。这将比默认会话状态提供程序快得多，因为您仅在需要信息时才获得信息！另外，您不必再背着默认会话对象。     ,扔更多的硬件！ 不，认真对于像您这样的站点，您可能会受益于将单独的计算机配置为会话状态服务器（请参阅MSDN文档），可以从IIS GUI或命令行执行此操作。 设置状态服务器后，需要设置Web配置以使用新计算机。这里提供了有关该过程的详细说明，但是总之，您可以如下设置web.config \的system.web.sessionState元素：

<?xml version=\"1.0\"?>
<configuration>
    <system.web>
        <sessionState
            mode=\"StateServer\"
            stateConnectionString=\"tcpip=your_server_ip:42424\"
            cookieless=\"false\"
            timeout=\"20\" />
    </system.web>
</configuration>

现在，如果您想承担大量的工作，则可以拥有许多状态服务器，并编写自己的例程来解析哪个服务器包含您的会话状态。请在此处查看该过程的说明。此策略应帮助您无限期地扩展规模，而不必放弃对HttpSession的使用。     ,如果大多数请求仅要求对该会话具有读取权限，那么您有一个简单的解决方案。将“ 1”属性设置为ReadOnly，它们仅在会话上获得只读锁。我不确定如何将其应用于网络服务，但是我确定有相同的设置。 http://msdn.microsoft.com/zh-CN/library/aa479041.aspx#aspnetsessionstate_topic3 除此之外，ASP.NET在每个请求的整个持续时间内锁定会话对象，并有效地序列化请求。允许请求并行运行的一种解决方案是不使用内置会话并推出自己的解决方案。这样做的好处是您可以使用更细粒度的锁定，因此请求的某些方面将必须同步并且可以串行运行，但是每个请求的大多数都可以并行运行。 另一种解决方案是简单地减少每个请求的并行调用数。请勿尝试并行运行它们。在客户端对它们进行批处理并将其作为单个请求发送。最终，请求数量的开销将减少，单个客户端占用大量资源的可能性也将降低，并且很可能可以为每个聚合请求总体上获得更好的性能。     ,如果没有看到您的代码或会话中正在加载和存储的内容，很难真正为您提供帮助。但是，以我的经验，会议延迟0.5秒肯定是不正常的。我非常希望看到您所指的文档说的是这样。 编写精良的asp.net（无论是Webforms，asmx，mvc还是其他选项）肯定是非常可扩展的。 话虽如此，您的会话存储在哪里？进行中？ IIS状态服务器？在数据库中？您在会话中实际存储了多少数据？您是否真的在几乎每个请求中都使用了加载到会话中的所有数据？ 在不更好地了解问题域的情况下，很难给出真实的答案：必须保持状态的状态，保持状态所使用的对象的大小，所拥有的流量等等。