问题描述
||
在与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提供了一种简单的方法，可以让您一次流汗，永不回头。但是这种方法看起来不太可行。
一种方法可能是消除单一的元数据收集神类，并将这种一神论类发展为半神半神的多神论集合。可以以较低的成本更频繁地安装半神人。可行，但需要大量重构，大量开发和质量检查时间。另一个候选人只是将所有状态信息存储在数据库中，但这有其自身的成本-延迟并不是最不重要的。
对于此问题是否还有其他解决方案，可能需要较少的精力来实施？
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）