next boost
Metrics support and cache status header
next-boost добавляет кэш-уровень в ваши приложения SSR (рендеринг на стороне сервера). Первоначально он был построен для Next.js и должен работать с любым приложением Node.js http.Server .
next-boost достигает отличной производительности, отображая веб-страницы на worker_threads , обслуживая кэшированную в главном потоке.
Если вы знакомы с Next.js , next-boost можно рассматривать как реализацию инкрементной статической регенерации, которая работает с getServerSideProps . И это не предназначено для использования с getStaticProps , в котором Next.js сделает для вас кэш.
$ 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 для SSR.next-boost.redis.js для образца конфигурации.next-boost.hdc.js для примера конфигурации next-boost с Next.js После установки пакета просто измените сценарий начала с next start на next-boost . Все аргументы командной строки next start , такие как -p для определения порта, совместимы.
"scripts": {
...
"start": "next-boost", // previously `next start`
...
},
Есть пример examples/nodejs , который работает с простым http.Server .
Чтобы использовать его с express.js и next.js , пожалуйста, проверьте examples/with-express .
Используя worker_threads , перевозит CPU-тяжелый SSR-рендеринг.
Вот сравнение использования ApacheBench в блоге, извлеченном из базы данных. HTML Prerendered и операция БД занимает около 10 ~ 20 мс. Страница занимает около 200 мс для lete.js для рендеринга.
$ /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
С CLI Next-Boost 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
Он даже превосходит статическую страницу сгенерированной getStaticProps .
next-boost реализует кэш на стороне сервера в способе устаревшего, который будет ревалидат. Когда доступ к истечению ( stale ) странице, кэш будет обслуживаться, и в то же время фоновый процесс принесет последнюю версию ( revalidate ) этой страницы и сохранит ее в кэше.
Следующая конфигурация будет кэшировать сопоставление URI ^/blog.* . Только страницы, соответствующие rules соответствия, будут обрабатываться next-boost , и нет никаких правил exclude .
module . exports = {
rules : [ { regex : '^/blog.*' , ttl : 300 } ] ,
}Есть 2 параметра для управления поведением кеша:
ttl (time-to-live) : через секунды ttl кэш будет переосмыслен. И ttl кэшированной страницы будет обновлен при переоценке страницы.tbd (time-before-deletion) : когда страница больше не нажимает в ttl + tbd секунд, она будет полностью удалена из кеша. Вверху: только кэширование страниц с URL начинается с /blog .
Отправляя get with Header x-next-boost:update на URL, кэш будет переосмыслен. И если страница больше не существует, кэш будет удален.
$ curl -H x-next-boost:update https://the_server_name.com/path_aЕсли вы хотите сразу удалить страницы развлечения, вы можете напрямую запустить SQL на кэше:
sqlite3 /cache_path/cache.db " update cache set ttl=0 where key like '%/url/a%'; " Это заставит все URL, содержащие /url/a быть переосмысленным при следующем случае.
Удаление 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
}
}В то время как вам нужно будет написать сложное правило режима или потенциально больше правил, это легко сделать с помощью логики JS.
В конце концов, если вы предпочитаете писать корпорацию, но хотите использовать логику JS, вы всегда можете соответствовать повторному обработке правил.
Если будет .next-boost.js . Если вы используете программно следующим образом, имя файла может быть изменено в опциях, которые вы передали в CachedHandler .
Советы: если вы используете CLI next-boost с next.js, вы можете использовать файл конфигурации.
И вот пример .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 , вы можете отключить журналы, передавая quiet логический флаг в качестве опции для CachedHandler .
...
const cached = await CachedHandler ( args , { quiet : true } ) ;
... Есть также флаг --quiet , если вы используете командную строку.
next-boost ограничена. До тех пор, пока URL не будет достигнут на каждом бэкэнд -сервере, он все еще может пропустить кэш. Используйте обратный прокси с поддержкой кэша (Nginx, Varnish и т. Д.) Для этого.GET и только запросы HEAD .worker_threads , и это функция Node.js 12+. next-boost работает в качестве замены на месте для next start с помощью функции пользовательского сервера Next.js.
На связанной странице выше вы можете увидеть следующее уведомление:
Прежде чем принять решение использовать пользовательский сервер, имейте в виду, что его следует использовать только тогда, когда интегрированный маршрутизатор next.js не может соответствовать требованиям вашего приложения. Пользовательский сервер удалит важные оптимизации производительности, такие как без сервера функции и автоматическая статическая оптимизация.
Next-Boost предназначен для использования в облачных VPS или контейнерах, поэтому без сервера функция здесь не является проблемой. Что касается Automatic Static Optimization , потому что мы не делаем ни одного app.render Рендер здесь, оно все еще работает, как всегда идеально.
Вот статья о том, когда не использовать SQLite. А для основной душительной перемещения следующего буста: супер более быстрый SSR на недорогих VPS, насколько я знаю, это лучший выбор.
Грань Copyright 2020 Rakuraku Jyo.
