雖然 Vue 的服務器端渲染 (SSR) 相當快速，但是由于需要為每次請求為了避免交叉請求狀態(tài)污染，都創(chuàng)建一個新的根Vue實例，創(chuàng)建組件實例和虛擬 DOM 節(jié)點的開銷，無法與純基于字符串拼接的模板的性能相當。在 SSR 性能至關重要的情況下，明智地利用緩存策略，可以極大改善響應時間并減少服務器負載。同時還可以大大減少后端接口服務器的負載。

在 vue SSR指南 中，緩存有兩種，分為頁面級緩存和組件級緩存。本次講的是頁面緩存，如果內(nèi)容不是用戶特定的并且在相對較短時間內(nèi)，頁面內(nèi)容不需要更新。我們就可以使用頁面緩存。對于頁面級緩存我們可以通過這段koa服務器的代碼大概知道緩存的思路：

const microCache = LRU({
 max: 100,
 maxAge: 1000 // 重要提示：條目在 1 秒后過期。
})

const isCacheable = req => {
 // 實現(xiàn)邏輯為，檢查請求是否是用戶特定(user-specific)。
 // 只有非用戶特定 (non-user-specific) 頁面才會緩存
}

server.get('*', (req, res) => {
 const cacheable = isCacheable(req)
 if (cacheable) {
 const hit = microCache.get(req.url)
 if (hit) {
  return res.end(hit)
 }
 }

 renderer.renderToString((err, html) => {
 res.end(html)
 if (cacheable) {
  microCache.set(req.url, html)
 }
 })
})

流程圖如下：

上面的代碼為vue的ssr渲染提供了方案，但是對于使用nuxt框架的同學而言，用腳手架初始化完，框架對于vue服務端渲染的res.end()函數(shù)做了高度封裝，從下圖nuxt在接收到請求后進行渲染的流程可以看出，nuxt主要是通過nuxtMiddleware調(diào)用renderRoute()來進行渲染的：

那么我們是否可以通過重寫renderRoute()這個api攔截其內(nèi)部渲染邏輯，在渲染之前加上緩存呢？ nuxt-ssr-cache 插件已經(jīng)這樣做了。我們來看一下這個nuxt模塊核心部分的源碼：

const renderer = nuxt.renderer;
const renderRoute = renderer.renderRoute.bind(renderer);
renderer.renderRoute = function(route, context) {
 // hopefully cache reset is finished up to this point.
 tryStoreVersion(cache, currentVersion);

 const cacheKey = (config.cache.key || defaultCacheKeyBuilder)(route, context);
 if (!cacheKey) return renderRoute(route, context);

 function renderSetCache(){
  return renderRoute(route, context)
   .then(function(result) {
    if (!result.error) {
     cache.setAsync(cacheKey, serialize(result));
    }
    return result;
   });
 }

 return cache.getAsync(cacheKey)
  .then(function (cachedResult) {
   if (cachedResult) {
    return deserialize(cachedResult);
   }

   return renderSetCache();
  })
  .catch(renderSetCache);
};

在這段代碼中，先保存了renderer原來的renderRoute代碼，之后又重寫了renderRoute代碼，返回了一個通過cache緩存來獲取緩存內(nèi)容的邏輯。cache返回了一個promise，如果是resolve的，并且有緩存的內(nèi)容，就直接返回緩存內(nèi)容。如果沒有緩存內(nèi)容或者reject，就執(zhí)行renderSetCache()。而renderSetCache()中，返回了原來最初的renderRoute()處理邏輯，同樣如果renderRoute()返回的promise被resolve了，那么就通過cache的setAsync方法來進行緩存，之后返回渲染結(jié)果。

使用方法大家自行參考git中的readme文檔，這里就不說了。

下面我們真正來仿真一下，看看這個模塊的功效到底如何。我們通過ab命令

ab -n 4000 -c 50 -s 120 -r http://localhost:3000/

來進行壓測：

第一種情況，沒有添加頁面緩存，大約持續(xù)請求了10秒鐘，執(zhí)行到3600個請求的時候，發(fā)生錯誤，不再繼續(xù)請求了：

我們來通過日志看下是什么錯誤：

可以看到FATAL ERROR這一句，JavaScript heap out of memory。堆內(nèi)存已經(jīng)沒有辦法再進行分配，所以進程終止了。

我們在終止之前通過進程監(jiān)視器可以看到node進程已經(jīng)彪到了1.7GB的內(nèi)存。

第二種情況，我們添加了頁面緩存，通過server端的日志，我們可以看出，只請求了一次后端的api數(shù)據(jù)接口，說明緩存已經(jīng)成功攔截了頁面請求。請求數(shù)據(jù)如下：

在2秒鐘之內(nèi)，就順利結(jié)束了4000個請求，內(nèi)存沒有任何明顯波動，優(yōu)化效果顯而易見。

到此這篇關于Nuxt頁面級緩存的實現(xiàn)的文章就介紹到這了,更多相關Nuxt 頁面級緩存內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論