next boost
Metrics support and cache status header
next-boost agrega una capa de caché a sus aplicaciones SSR (reproducción del lado del servidor). Fue construido originalmente para Next.js y debería funcionar con cualquier aplicación basada en Node.js http.Server .
next-boost logra un gran rendimiento al presentar páginas web en worker_threads mientras sirve el almacenamiento en caché en el hilo principal.
Si está familiarizado con Next.js , next-boost puede considerarse como una implementación de una regeneración estática incremental que funciona con getServerSideProps . Y no está destinado a usarse con getStaticProps , en los que Next.js hará el caché por usted.
$ 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 para SSR.next-boost.redis.js para la configuración de la muestra.next-boost.hdc.js para la configuración de la muestra next-boost con Next.js Después de instalar el paquete, simplemente cambie el script de inicio desde next start a next-boost . Todos los argumentos de la línea de comandos de next start , como -p para especificar el puerto, son compatibles.
"scripts": {
...
"start": "next-boost", // previously `next start`
...
},
Hay un ejemplo bajo examples/nodejs , que funciona con un http.Server simple.
Para usarlo con express.js y next.js , verifique examples/with-express .
Al usar worker_threads , la representación de SSR-Heavy CPU no bloqueará el proceso principal de servir al caché.
Aquí está la comparación del uso de ApacheBench en una publicación de blog obtenida de la base de datos. HTML Prerendered y la operación DB toma alrededor de 10 ~ 20 ms. La página tarda alrededor de 200 ms para el próximo.js para renderizar.
$ /usr/local/bin/ab -n 200 -c 8 http://127.0.0.1:3000/blog/posts/2020/3/postnameNo es un punto de referencia científico, pero las mejoras son visiblemente enormes.
con next start (datos obtenidos con 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
Con el STIL-Boost cli next-boost :
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
Incluso supera a la página estática generada de Next.js ( getStaticProps ), manejando 2 ~ 2.5x solicitudes por segundos en mi entorno.
next-boost implementa un caché del lado del servidor a la manera de revalidar. Cuando se accede a una página expirada ( stale ), se servirá el caché y, al mismo tiempo, un proceso de fondo obtendrá la última versión ( revalidate ) de esa página y la guardará en el caché.
La siguiente configuración almacenará en caché URIS Matching ^/blog.* . Solo rules de las páginas coinciden serán manejadas por next-boost y no hay reglas exclude .
module . exports = {
rules : [ { regex : '^/blog.*' , ttl : 300 } ] ,
}Hay 2 parámetros para controlar el comportamiento del caché:
ttl (time-to-live) : después de ttl segundos, el caché se revalidará. Y ttl de una página en caché se actualizará cuando se revalice una página.tbd (time-before-deletion) : cuando una página no se ve nuevamente en ttl + tbd segundos, se eliminará por completo de la memoria caché. Arriba: solo las páginas de almacenamiento en caché con URL comienzan con /blog .
Al enviar un Get With Header x-next-boost:update a la URL, el caché se revalinará. Y si la página ya no existe, el caché se eliminará.
$ curl -H x-next-boost:update https://the_server_name.com/path_aSi desea eliminar las páginas de Mutiple a la vez, puede ejecutar SQL en el caché directamente:
sqlite3 /cache_path/cache.db " update cache set ttl=0 where key like '%/url/a%'; " Esto obligará a que todas las URL que contengan /url/a se revaliden cuando se accedan la próxima vez.
Eliminar cache_path eliminará todos los cachés.
Por defecto, cada página con diferentes URL se almacenará en caché por separado. Pero en algunos casos le gustaría, /path_a?utm_source=twitter para ser atendido con el mismo contenido de /path_a . paramFilter es para filtrar los parámetros de consulta.
// in .next-boost.js
{
...
paramFilter : ( p ) = > p !== 'utm_source'
}Por defecto, la URL se utilizará como la clave para las páginas en caché. Si desea páginas de servidor de diferentes dominios o por diferentes agentes de usuario, puede usar esta función para personalizar la tecla de caché.
Notas:
string , su servidor se bloqueará. // in .next-boost.js
{
...
cacheKey : ( req ) = > ( req . headers . host || '' ) + ':' + req . url
}Alternativamente, puede proporcionar una función en lugar de una matriz dentro de su configuración.
// in .next-boost.js
{
...
rules : ( req ) = > {
if ( req . url . startsWith ( '/blog' ) ) {
return 300
}
}
} La función debe devolver ttl válido para la solicitud. Si la función devuelve 0 o el valor falsy , la solicitud no se almacenará en caché.
El poder que proviene de este método es que puede decidir si la solicitud se almacena en caché o no más dinámicamente.
Por ejemplo, puede ignorar automáticamente todas las solicitudes de usuarios autenticados en función del encabezado:
// in .next-boost.js
{
...
rules : ( req ) = > {
if ( req . headers . authorization ) {
return false
}
return 10 // cache all other requests for 10 seconds
}
}También puede hacer reglas más complejas más fácilmente que a través de Regex. Por ejemplo, desea diferente TTL para cada una de las páginas de paginación.
// 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
}
}Si bien necesitaría escribir una regla regular compleja o potencialmente más reglas, es fácil hacerlo a través de JS Logic.
Al final, si prefiere escribir regex pero desea aprovechar la lógica JS, siempre puede coincidir con el manejador de reglas.
Si está disponible, se utilizará .next-boost.js en Project Root. Si usa el siguiente-boost programáticamente, el nombre de archivo se puede cambiar en las opciones que pasó a CachedHandler .
Consejos: si está utilizando la CLI next-boost con Next.js, es posible que desee usar el archivo de configuración.
Y aquí hay un ejemplo .next-boost.sample.js en el repositorio.
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 El registro está habilitado de forma predeterminada. Si usa next-boost mediante programación, puede deshabilitar los registros pasando la bandera booleana quiet como una opción para CachedHandler .
...
const cached = await CachedHandler ( args , { quiet : true } ) ;
... También hay una bandera --quiet si está utilizando la línea de comandos.
next-boost es limitado. Hasta que la URL se presione en cada servidor de backend, aún puede perderse el caché. Use proxy inverso con soporte de caché (NGINX, barniz, etc.) para eso.GET solo solicitudes HEAD .worker_threads se usa y es una función Node.js 12+. next-boost funciona como un reemplazo en el lugar para next start utilizando la función de servidor personalizado de Next.js.
En la página vinculada arriba, puede ver el siguiente aviso:
Antes de decidir usar un servidor personalizado, tenga en cuenta que solo debe usarse cuando el enrutador integrado de Next.js no puede cumplir con los requisitos de su aplicación. Un servidor personalizado eliminará importantes optimizaciones de rendimiento, como funciones sin servidor y optimización estática automática.
El próximo boost está destinado a usarse en VPS o contenedores en la nube, por lo que la función sin servidor no es un problema aquí. En cuanto a Automatic Static Optimization , porque no estamos haciendo ninguna app.render aquí, todavía funciona, tan perfecta como siempre.
Aquí está el artículo sobre cuándo no usar SQLite. Y para el principal propósito de Boost: SSR súper más rápido en VPS de bajo costo, que yo sepa, es la mejor opción.
Mit. Copyright 2020 Rakuraku Jyo.
