javascript和asp.net的緩存問題

Question

我剛才在這里問了一個有關為日歷/計划Web應用程序緩存數據的問題，並得到了一些很好的答復。 但是，我現在決定更改我的方法，並統計將數據緩存在javascript中。

我直接在$（'body'）。data（）對象內的日歷網格中為每一天的列緩存HTML，這提供了非常快的頁面加載時間（幾乎不引人注意）。

但是，當用戶請求尚未在緩存中的數據時，就會出現問題。 該數據是由服務器使用ajax調用創建的，因此它是異步的，每周大約需要0.2s的數據。

我當前的方法只是在用戶從服務器請求信息時阻塞0.5s，並在初始頁面加載的每一側緩存4周（每個頁面更改請求額外緩存1周），但是我懷疑這是否是最佳方法。

有沒有人建議如何改善這種情況？

總結一下：

• 每周需要0.2秒的時間從服務器異步獲取數據。
• 性能必須盡可能接近實時。 （但是不需要數據是完全實時的：大多數約會是由用戶添加的，因此我們可以在此之后重新緩存）
• 當前在初始周的任一側都緩存了4周：這還不夠。
• 緩存1年大約需要21秒，對於初始加載來說這太慢了。

Answer 1

在閱讀您的描述時，我想到了兩件事：異步和緩存。

一，異步

你為什么要阻擋0.5秒？ 為什么不使用ajax調用，並在回調中使用檢索到的信息更新頁面。 在設定的時間內沒有阻塞，它是異步完成的。 盡管請求懸而未決，但是您必須抑制多次單擊，但這根本不是問題。

您還可以使用setInterval或更好的setTimeout在后台預加載頁內緩存。 如果計算或生成日歷的成本很高並且數據大小相對較小，換句話說，即使它從未使用過，也足夠小以至於可以在頁內緩存中存儲數月，這特別有意義。 聽起來您無論如何都可以這樣做，並且僅在用戶跳出緩存數據范圍時才需要阻塞。

智能緩存

我在想象回調函數-ajax調用完成時調用的函數-將檢查當前選擇的日期是否在緩存數據的“邊緣”上-緩存的第一周還是最后一周（或其他） 。 如果用戶處在邊緣狀態，則回調可以發出額外的請求，以樂觀地預加載高速緩存，直到4周的限制，或在您的80％用例有意義的任何時間范圍內。

您還可以考慮按用戶在服務器端緩存生成的日歷數據。 如果生成這些東西需要占用大量CPU和時間，那么一次生成並將其保存在服務器端緩存中是一個不錯的選擇，只有在用戶進行更新時才使它無效。 使用x64服務器和廉價內存，這可能非常可行。 根據用例的不同，它可能會使用戶第二次連接到應用程序，從而使交互作用更加實用。 您甚至可以考慮在用戶請求任何日歷之前按用戶預先加載服務器端緩存。