javascript和asp.net的缓存问题

刚才我问了一个关于为日历/日程安排web应用缓存数据的问题，得到了一些很好的回答。然而，我现在决定改变我的方法，用javascript对数据进行静态缓存

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

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

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

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

总结如下：

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

---

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

首先，异步

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

您还可以在后台使用

setInterval

或更好的

setTimeout

预加载页内缓存。如果计算或生成日历的成本很长，并且数据大小相对较小（换句话说，即使从未使用过，也足够小，可以在页内缓存中存储月份），那么这一点尤其有意义。听起来您可能正在执行此操作，并且只需要在用户跳出缓存数据范围时进行阻止

智能缓存

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

---

您还可以考虑在每个用户的基础上缓存服务器端生成的日历数据。如果生成这些东西需要CPU和时间，那么生成一次并将其保存在服务器端缓存中应该是一个不错的选择，只有在用户进行更新时才会失效。对于x64服务器和廉价内存，这可能是非常可行的。根据使用情况，它可能会使用户第二次连接到应用程序时的交互更加可用。您甚至可以考虑在用户请求任何日历之前按每个用户预先加载服务器端缓存。 这可能是OT，也不打算以任何方式成为sarky：您可以对服务器端时间做些什么吗？我很惊讶，您可以在~0.2秒内返回一周，但两周需要~0.4秒。对于大多数后端，我预计两周的时间几乎与一周的时间一样长，其中大部分时间是设置请求、检查数据库池中的连接等，而不是实际的查询。但同样，这可能是OT，并且肯定是基于对您的基础架构的无知。：-）是的，我认为需要更多关于您在服务器上所做工作的信息。你的减速在哪里？当然，它通常在DB中，但可能是其他的。不，这是一个公平的评论：我实际上计算了传输时间（包括它们，它接近于0.5）：我不想指望传输速度：这是在我的本地ASP.net开发环境中运行的（在调试中），因此，无法保证它们在实时服务器上之后会是相同的，特别是因为实时设置是负载平衡的，因此由于路由等原因，性能会发生变化。一年的20秒数字包括传输。我认为从数据源转换为HTML需要1周多的时间。@wvdomick数据直接来自数据库：实际上没有办法预缓存它。另外还有创建html的开销，令人惊讶的是很难让约会正确排列等等。当您可以有多个并发约会时，这会导致一个相当可怕的O（nlogn）函数在每个输出日调用一次。这听起来很复杂，CPU很重，我很想遵从GCal over API:）异步：是的，我实际上使用了page方法的回调来重新调用缓存，它似乎工作正常。我正在阻止使用UpdatePanel，因为它更容易确保用户在请求发布时不能点击任何东西，并保证该周的快速恢复。至于智能缓存，由于没有足够的时间进行检查并取回数据，因此很难通过反复点击“下一步”按钮来处理用户试图导航到某一周的情况。至于服务器端缓存，在组环境中并不切实可行，很有可能让另一个用户在注销或登录时更改约会。如果是纯客户端，则在再次加载页面时会刷新，这确保了数据的安全性