Nuxt 페이지 급 캐 시 구현

Vue 의 서버 엔 드 렌 더 링(SSR)이 상당히 빠 르 지만 요청 할 때마다 교차 요청 상태 오염 을 피하 기 위해 새 루트 Vue 인 스 턴 스 를 만 들 고 구성 요소 인 스 턴 스 와 가상 DOM 노드 를 만 드 는 비용 이 필요 하기 때문에 문자열 기반 템 플 릿 의 성능 과 맞 먹 을 수 없습니다.SSR 성능 이 중요 한 상황 에서 캐 시 정책 을 현명 하 게 활용 하면 응답 시간 을 크게 개선 하고 서버 부 하 를 줄 일 수 있다.백 엔 드 인터페이스 서버 의 부하 도 크게 줄 일 수 있다.
vue SSR 가이드 에서 캐 시 는 두 가지 가 있 는데 페이지 급 캐 시 와 구성 요소 급 캐 시 로 나 뉜 다.이번 에는 페이지 캐 시 를 말 합 니 다.내용 이 사용자 가 지정 하지 않 고 상대 적 으로 짧 은 시간 안에 페이지 내용 을 업데이트 할 필요 가 없습니다.우 리 는 페이지 캐 시 를 사용 할 수 있다.페이지 급 캐 시 에 대해 서 는 이 koa 서버 의 코드 를 통 해 캐 시 방향 을 대충 알 수 있 습 니 다.

const microCache = LRU({
 max: 100,
 maxAge: 1000 //     ：    1     。
})

const isCacheable = req => {
 //      ，           (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()함수 에 대해 고도 로 패 키 징 되 었 습 니 다.다음 그림 nuxt 에서 요청 을 받 은 후에 렌 더 링 하 는 절 차 를 통 해 알 수 있 듯 이 nuxt 는 주로 nuxtMiddleware 를 통 해 renderRoute()를 호출 하여 렌 더 링 합 니 다.

그러면 우 리 는 renderRoute()라 는 api 를 다시 써 서 내부 렌 더 링 논 리 를 차단 하고 렌 더 링 하기 전에 캐 시 를 추가 할 수 있 습 니까?nuxt-ssr-cache 플러그 인 은 이미 이렇게 했다.이 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 캐 시 를 통 해 캐 시 내용 을 가 져 오 는 논 리 를 되 돌려 줍 니 다.cache 는 promise 를 되 돌려 주 었 습 니 다.resolve 이 고 캐 시 내용 이 있 으 면 캐 시 내용 을 되 돌려 줍 니 다.캐 시 내용 이나 reject 가 없 으 면 renderSetCache()를 실행 합 니 다.그리고 renderSetCache()에 서 는 원래 의 renderRoute()처리 논 리 를 되 돌려 주 었 습 니 다.마찬가지 로 renderRoute()가 되 돌아 온 promise 가 resolve 되면 cache 의 setAsync 방법 으로 캐 시 를 한 다음 렌 더 링 결 과 를 되 돌려 줍 니 다.
사용 방법 은 git 의 readme 문 서 를 참고 하 십시오.여 기 는 말 하지 않 겠 습 니 다.
다음은 이 모듈 의 효능 이 도대체 어떤 지 본 떠 보 자.우 리 는 ab 명령 을 통 해

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

압력 측정 을 진행 합 니 다:
첫 번 째 상황 은 페이지 캐 시 를 추가 하지 않 고 약 10 초 동안 요청 을 했 습 니 다.3600 개의 요청 을 실 행 했 을 때 오류 가 발생 하여 더 이상 요청 하지 않 습 니 다.

로 그 를 통 해 어떤 오류 가 있 는 지 알 아 보 겠 습 니 다.

FATAL ERROR 라 는 말 을 볼 수 있 습 니 다.JavaScript heap out of memory.메모리 더 이상 할당 할 방법 이 없어 서 프로 세 스 가 종료 되 었 습 니 다.
종료 하기 전에 프로 세 스 모니터 를 통 해 node 프로 세 스 가 1.7GB 메모리 에 표 시 된 것 을 볼 수 있 습 니 다.

두 번 째 상황 은 페이지 캐 시 를 추 가 했 습 니 다.server 엔 드 로 그 를 통 해 백 엔 드 api 데이터 인터페이스 만 요청 한 것 을 알 수 있 습 니 다.캐 시가 페이지 요청 을 성공 적 으로 차단 했다 는 것 을 설명 합 니 다.요청 데 이 터 는 다음 과 같 습 니 다.

2 초 만 에 4000 개의 요청 이 순조롭게 끝 났 고 메모리 에 뚜렷 한 파동 이 없 으 며 최적화 효과 가 뚜렷 하 다.
여기 서 Nuxt 페이지 급 캐 시 실현 에 관 한 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 Nuxt 페이지 급 캐 시 내용 은 예전 의 글 을 검색 하거나 아래 의 관련 글 을 계속 찾 아 보 세 요.앞으로 도 많은 응원 부 탁 드 리 겠 습 니 다!