next boost
Metrics support and cache status header
next-boost SSR (Server-Side Rendering) 응용 프로그램에 캐시 레이어를 추가합니다. 원래 Next.js 용으로 제작되었으며 Node.js http.Server 기반 응용 프로그램에서 작업해야합니다.
next-boost 메인 스레드에서 캐싱을 제공하는 동안 worker_threads 의 웹 페이지를 렌더링하여 훌륭한 성능을 달성합니다.
Next.js 에 익숙한 경우 next-boost getServerSideProps 와 함께 작동하는 증분 정적 재생의 구현으로 간주 될 수 있습니다. 그리고 그것은 getStaticProps 와 함께 사용되는 것이 아닙니다.
$ yarn add @next-boost/next-boost
$ yarn add @next-boost/redis-cache # using load-balancer and cluster
$ yarn add @next-boost/hybrid-disk-cache # simple site with disk cache next startworker_threads 사용을위한 비 블로킹 기본 프로세스.next-boost.redis.js 확인하십시오.next-boost.hdc.js 확인하십시오 next-boost CLI를 사용하십시오 패키지를 설치 한 후 다음 시작에서 next start 에서 next-boost 로 시작 스크립트를 변경하십시오. 포트를 지정하기위한 -p 와 같은 next start 의 명령 줄 인수는 호환됩니다.
"scripts": {
...
"start": "next-boost", // previously `next start`
...
},
examples/nodejs 아래에는 일반 http.Server 와 함께 작동하는 예가 있습니다.
express.js 및 next.js 와 함께 사용하려면 examples/with-express 확인하십시오.
worker_threads 사용하면 CPU-Heavy SSR 렌더링은 기본 프로세스가 캐시를 제공하는 것을 차단하지 않습니다.
다음은 데이터베이스에서 가져온 블로그 게시물에서 ApacheBench 사용하는 비교입니다. HTML 프레 렌드 및 DB 작업은 약 10 ~ 20ms가 소요됩니다. 다음 페이지는 렌더링하는 데 약 200ms가 걸립니다.
$ /usr/local/bin/ab -n 200 -c 8 http://127.0.0.1:3000/blog/posts/2020/3/postname과학적 벤치 마크는 아니지만 개선은 눈에 띄게 엄청납니다.
next start 으로 ( getServerSideProps 와 함께 데이터를 가져온 데이터) :
Document Length: 76424 bytes
Concurrency Level: 8
Time taken for tests: 41.855 seconds
Complete requests: 200
Failed requests: 0
Total transferred: 15325600 bytes
HTML transferred: 15284800 bytes
Requests per second: 4.78 [#/sec] (mean)
Time per request: 1674.185 [ms] (mean)
Time per request: 209.273 [ms] (mean, across all concurrent requests)
Transfer rate: 357.58 [Kbytes/sec] received
드롭 인 next-boost CLI와 함께 :
Document Length: 78557 bytes
Concurrency Level: 8
Time taken for tests: 0.149 seconds
Complete requests: 200
Failed requests: 0
Total transferred: 15747600 bytes
HTML transferred: 15711400 bytes
Requests per second: 1340.48 [#/sec] (mean)
Time per request: 5.968 [ms] (mean)
Time per request: 0.746 [ms] (mean, across all concurrent requests)
Transfer rate: 103073.16 [Kbytes/sec] received
내 환경에서 초당 2 ~ 2.5 배의 요청을 처리하는 다음 Next.js의 정적 생성 페이지 ( getStaticProps )보다 성능이 우수합니다.
next-boost 오래된 while-revalidate의 방식으로 서버 측 캐시를 구현합니다. 만료 된 ( stale ) 페이지에 액세스하면 캐시가 제공되고 동시에 배경 프로세스가 해당 페이지의 최신 버전 ( revalidate )을 가져와 캐시에 저장합니다.
다음 구성은 Uris와 일치하는 ^/blog.* . 페이지 일치 rules 만 next-boost 로 처리되며 규칙 exclude 없습니다.
module . exports = {
rules : [ { regex : '^/blog.*' , ttl : 300 } ] ,
}캐시의 동작을 제어하는 두 가지 매개 변수가 있습니다.
ttl (time-to-live) : ttl 초 후에 캐시가 재평가됩니다. 캐시 된 페이지의 ttl 페이지가 재평가되면 업데이트됩니다.tbd (time-before-deletion) : ttl + tbd Seconds에서 페이지를 다시 누르지 않으면 캐시에서 완전히 제거됩니다. 위 : URL이있는 캐싱 페이지 만 /blog 로 시작합니다.
헤더 x-next-boost:update 보내면 캐시가 재평가됩니다. 페이지가 더 이상 존재하지 않으면 캐시가 삭제됩니다.
$ curl -H x-next-boost:update https://the_server_name.com/path_aMutiple Pages를 한 번에 삭제하려면 캐시에서 직접 SQL을 실행할 수 있습니다.
sqlite3 /cache_path/cache.db " update cache set ttl=0 where key like '%/url/a%'; " 이렇게하면 다음에 액세스 할 때 /url/a 포함하는 모든 URL이 재평가되도록합니다.
cache_path 삭제하면 모든 캐시가 제거됩니다.
기본적으로 URL이 다른 각 페이지는 별도로 캐시됩니다. 그러나 어떤 경우에는 /path_a?utm_source=twitter /path_a 의 동일한 내용을 제공합니다. paramFilter 쿼리 매개 변수를 필터링하기위한 것입니다.
// in .next-boost.js
{
...
paramFilter : ( p ) = > p !== 'utm_source'
}기본적으로 URL은 캐시 된 페이지의 키로 사용됩니다. 다른 도메인의 서버 페이지 또는 다른 사용자 에이전트로 서버 페이지를 원한다면이 기능을 사용하여 캐시 키를 사용자 정의 할 수 있습니다.
참고 :
string 아닌 경우 서버가 충돌합니다. // in .next-boost.js
{
...
cacheKey : ( req ) = > ( req . headers . host || '' ) + ':' + req . url
}또는 구성 내부에서 배열 대신 함수를 제공 할 수 있습니다.
// in .next-boost.js
{
...
rules : ( req ) = > {
if ( req . url . startsWith ( '/blog' ) ) {
return 300
}
}
} 함수는 요청에 대해 유효한 ttl 반환해야합니다. 함수가 0 또는 falsy 값을 반환하면 요청이 캐시되지 않습니다.
이 방법에서 나오는 힘은 요청이 동적인지 여부를 결정할 수 있다는 것입니다.
예를 들어 헤더를 기반으로 인증 된 사용자의 모든 요청을 자동으로 무시할 수 있습니다.
// in .next-boost.js
{
...
rules : ( req ) = > {
if ( req . headers . authorization ) {
return false
}
return 10 // cache all other requests for 10 seconds
}
}REGEX를 통해 더 쉽게 복잡한 규칙을 수행 할 수 있습니다. 예를 들어 각 페이지 매김 페이지마다 다른 TTL을 원합니다.
// in .next-boost.js
{
...
rules : ( req ) = > {
const [ , p1 ] = url . split ( '?' , 2 )
const params = new URLSearchParams ( p1 )
return {
1 : 5000 ,
2 : 4000 ,
3 : 3000 ,
4 : 2000
} [ params . get ( 'page' ) ] || 1000
}
}복잡한 Regex 규칙 또는 잠재적으로 더 많은 규칙을 작성해야하지만 JS 논리를 통해 쉽게 수행 할 수 있습니다.
결국 Regex를 작성하는 것을 선호하지만 JS 로직을 활용하려면 항상 규칙 핸들러 내에서 일치 할 수 있습니다.
사용 가능한 경우 프로젝트 루트에서 .next-boost.js 사용됩니다. 다음 부스트를 프로그래밍 방식으로 사용하는 경우 CachedHandler 로 전달한 옵션에서 파일 이름을 변경할 수 있습니다.
팁 : Next.js와 함께 next-boost CLI를 사용하는 경우 구성 파일을 사용할 수 있습니다.
그리고 여기에 예를 .next-boost.sample.js .
interface HandlerConfig {
filename ?: string
quiet ?: boolean
cache ?: {
ttl ?: number
tbd ?: number
path ?: string
}
rules ?: Array < URLCacheRule > | URLCacheRuleResolver
paramFilter ?: ParamFilter
cacheKey ?: CacheKeyBuilder
}
interface URLCacheRule {
regex : string
ttl : number
}
type URLCacheRuleResolver = ( req : IncomingMessage ) => number
type ParamFilter = ( param : string ) => boolean
type CacheKeyBuilder = ( req : IncomingMessage ) => string 로깅은 기본적으로 활성화됩니다. 프로그래밍 방식으로 next-boost 사용하는 경우 CachedHandler 의 옵션으로 quiet 부울 깃발을 전달하여 로그를 비활성화 할 수 있습니다.
...
const cached = await CachedHandler ( args , { quiet : true } ) ;
... 명령 줄을 사용하는 경우 --quiet 플래그도 있습니다.
next-boost 사용의 이점이 제한됩니다. 모든 백엔드 서버에서 URL이 닿을 때까지 여전히 캐시를 놓칠 수 있습니다. 이를 위해 캐시 지지대 (Nginx, 바니시 등)와 함께 리버스 프록시를 사용하십시오.GET HEAD 요청 만하십시오.worker_threads 사용되며 Node.js 12+ 기능입니다. next-boost Next.js의 사용자 정의 서버 기능을 사용하여 next start 위한 내내 교체로 작동합니다.
위의 링크 된 페이지에서 다음과 같은 통지를 볼 수 있습니다.
사용자 정의 서버를 사용하기로 결정하기 전에 Next.js의 통합 라우터가 앱 요구 사항을 충족 할 수없는 경우에만 사용해야합니다. 사용자 정의 서버는 서버리스 기능 및 자동 정적 최적화와 같은 중요한 성능 최적화를 제거합니다.
다음 부스트는 클라우드 VPS 또는 컨테이너에 사용되므로 서버리스 기능이 문제가되지 않습니다. Automatic Static Optimization 에 관해서는 app.render 수행하지 않기 때문에 항상 완벽하게 작동합니다.
다음은 SQLITE를 사용하지 않을 때에 관한 기사입니다. 그리고 Next-Boost의 Main Purpuse : 저비용 VPS에서 Super Faster SSR의 경우, 내가 아는 한, 그것은 최선의 선택입니다.
MIT. 저작권 2020 Rakuraku Jyo.
