asp.net - javascript 和 asp.net 的缓存问题

Question

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

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

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

我当前的方法是简单地在用户从服务器请求信息时阻塞 0.5 秒，并在初始页面加载的两侧缓存 4 周(每个页面更改请求额外缓存 1 周)，但是我怀疑这是最优方法。

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

总结一下:

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

Answer 1

当我阅读你的描述时，我想到了两件事:异步和缓存。

首先，异步

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

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

智能缓存

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

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