javascript 和 asp.net 的缓存问题答案

【问题标题】：Caching issue with javascript and asp.netjavascript 和 asp.net 的缓存问题
【发布时间】：2010-03-16 02:46:51
【问题描述】：

不久前我在这里问了一个关于为日历/日程安排网络应用程序缓存数据的问题，并得到了一些很好的回应。但是，我现在决定改变我的方法并在 javascript 中缓存数据。

我在 $('body').data() 对象内的日历网格中直接缓存每一天的列的 HTML，这提供了非常快的页面加载时间（几乎不引人注意）。

但是，当用户请求尚未在缓存中的数据时，就会出现问题。该数据由服务器使用 ajax 调用创建，因此是异步的，每周大约需要 0.2 秒的数据。

我目前的方法是在用户从服务器请求信息时阻止 0.5 秒，并在初始页面加载的任一侧缓存 4 周（每个页面更改请求额外 1 周），但是我怀疑这是最佳方法。

有人对如何改善这种情况提出建议吗？

总结一下：

每周从服务器异步检索需要 0.2 秒。
性能必须尽可能接近实时。（但是数据不需要完全实时：大多数约会是由用户添加的，因此我们可以在此之后重新缓存）
目前在加载的初始周的任一侧缓存了 4 周：这还不够。
缓存 1 年大约需要 21 秒，这对于初始加载来说太慢了。

【问题讨论】：

这可能是 OT 并且不打算以任何方式变得刺耳：对于服务器端时间，您可以做些什么吗？我很惊讶你能在 0.2 秒内恢复一周，但两周需要 ~0.4 秒。对于大多数后端，我预计两周将花费几乎与一周一样多的时间，其中大部分时间用于设置请求、检查数据库池中的连接等等，等等，而不是实际查询。但同样，这可能是 OT 并且肯定基于对您的基础架构的无知。 :-)
是的，我认为需要更多关于您在服务器上执行的操作的信息。你的减速在哪里？通常它在数据库中，当然，但也许它是别的东西。
不，这是一个公平的评论：我实际上取出了传输时间（包括它们在内，它接近 0.5）：我不想指望传输速度：这是在我的本地运行目前 ASP.net 开发环境（调试中），因此无法保证它们在实时服务器上时会相同，特别是因为实时设置是负载平衡的，因此由于路由等而具有可变的性能. 一年的 20 多岁的数字包括转会费。我认为从数据源转换为 HTML 需要 1 周时间约 0.2 秒。
@WVDominick 数据直接来自数据库：实际上没有办法预先缓存它。还有创建 html 的开销，当您可以有多个并发约会时，让约会正确排列等非常困难，这导致每个输出日调用一次相当可怕的 O(nlogn) 函数。
这听起来很复杂而且 CPU 很重，我很想通过 API 遵循 GCal :)

标签： asp.net javascript jquery caching

【解决方案1】：

在阅读您的描述时，我想到了两件事：异步和缓存。

首先，异步

为什么要阻止 0.5 秒？为什么不使用 ajax 调用，并在回调中使用检索到的信息更新页面。在设定的时间内没有阻塞，它是异步完成的。尽管请求未完成，但您必须抑制多次点击，但这根本不是问题。

您还可以使用setInterval 或更好的setTimeout 在后台预加载页内缓存。如果计算或生成日历的成本很长并且数据大小相对较小 - 换句话说，小到足以在页内缓存中存储几个月，即使它从未使用过，这尤其有意义。听起来您可能正在这样做，并且只需要在用户跳出缓存数据范围时进行阻止。

智能缓存

我在想象回调函数——在 ajax 调用完成时调用的函数——将检查当前选择的日期是否在缓存数据的“边缘”——缓存中的第一周或上周（管他呢）。如果用户处于边缘，则回调可以发送一个额外的请求，以乐观地预加载缓存到 4 周的限制，或者任何对 80% 用例有意义的时间范围。

您也可以考虑在服务器端缓存每个用户生成的日历数据。如果生成这些东西是 CPU 和时间密集型的，那么生成一次并将其保存在服务器端缓存中应该是一个不错的交易，只有在用户进行更新时才会失效。使用 x64 服务器和便宜的内存，这可能是非常可行的。根据用例，它可能会产生更有用的交互，即用户第二次连接到应用程序。您甚至可以考虑在用户请求任何日历之前按用户预加载服务器端缓存。

【讨论】：

Asynchrony：是的，我实际上是在使用页面方法中的回调来重新调用缓存，它似乎工作正常。我阻止使用 UpdatePanel，因为它更容易确保用户在请求发布时无法点击任何内容，并保证该周的快速周转。至于智能缓存，很难处理用户试图通过反复单击“下一步”按钮导航到特定一周的情况，因为没有足够的时间进行检查并取回数据。
至于服务器端缓存，它在组环境中是不可行的，很有可能让另一个用户在他们注销时更改他们的约会，甚至在他们登录时。如果是纯粹的客户端，它们会在再次加载页面时刷新，从而确保数据总是相当新鲜。
关于“时间不够”的问题。 . .有一些方法可以智能地处理它。一种方法是通过 setTimeout 在单击和生成的 ajax 调用之间引入延迟。如果在延迟到期之前发生了额外的点击，则重置计时器并等待更多时间。您可以假设多个 Next clicks 将在彼此间隔 650 毫秒内发生（例如），因此如果您连续获得 3 次点击，然后延迟超过 650 毫秒，您知道在 3 周后请求，而不是“这个周”、“下周”和“下周”，带有 3 个单独的 ajax 调用。
我不同意这在小组环境中是不可行的。您正在寻找分布式内存缓存 (DMC)，请查看 Memcache、Velocity 等。当您遇到可扩展性问题并且您拥有负载平衡的环境时，您的下一步应该始终是 DMC 系统，在您通过分析验证您已经合理地通过代码执行实现了所有性能提升。
我同意 Marisic；不存在阻止您使用服务器端缓存的后勤障碍。分布式内存缓存将在整个场中很好地扩展。此外，您可以在使用缓存内容之前进行缓存验证检查，以避免后备存储已被其他应用程序更改的问题。另一方面，我知道您这样做可能不切实际。