缓存的问题使用JavaScript和asp.net

Question

我问一个问题了一段时间回来就在这里就为日历/调度Web应用程序的缓存数据，并得到了一些良好的反应。然而，我现在决定改变我的方法和统计数据缓存在JavaScript中。

我直接缓存在$（“身体”）内的日历网格每天的列中的HTML。数据（）对象，这给了非常快速的网页加载时间（几乎是容易被忽视的）。

然而，问题开始当用户请求数据尚未在高速缓存中出现。这些数据是由服务器使用ajax调用创建的，因此它是异步的，每周数据大约需要0.2s。

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

有没有人有一个建议就如何改善这种状况？

总结：

• 每个星期需要0.2秒，从服务器中检索，异步。
• 性能必须尽可能接近实时。 （但是不需要数据是完全实时的：大多数任命都是由用户添加的，所以我们可以重新缓存在此之后）
• 目前4周缓存上加载inial一周的两侧：这是不够。
• 缓存1年花费〜21S，这是初始加载速度太慢。

Answer 1

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

首先，异步性

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

您还可以在后台使用setInterval或更高版本，setTimeout预加载页内缓存。如果计算或生成日历的开销很大，并且数据量相对较小 - 换句话说，即使从未使用，也足够小到可以在页内缓存中存储数月，这一点尤其有意义。听起来你可能会这样做，只需要在用户跳出缓存数据范围时阻止。

智能高速缓存

我想象的回调函数 - Ajax调用完成时被调用的一个 - 将检查当前选定的日期是在高速缓存数据的“边缘” - 无论是第一周缓存或上周（或其他）。如果用户处于边缘，那么回调可以发出额外的请求来乐观地预加载缓存至4周的限制，或者任何时间范围对于80％的用例都有意义。

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