next boost
Metrics support and cache status header
next-boost SSR（サーバー側のレンダリング）アプリケーションにキャッシュレイヤーを追加します。当初はNext.js用に構築されていたため、node.js http.Serverベースのアプリケーションで動作するはずです。
next-boostメインスレッドでキャッシュされたものを提供しながら、 worker_threadsでWebページをレンダリングすることにより、優れたパフォーマンスを実現します。
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が多いSSRレンダリングは、メインプロセスがキャッシュの提供をブロックしません。
以下は、データベースから取得されたブログ投稿でApacheBenchを使用することの比較です。 HTMLプレレンダーとDB操作には約10〜20msがかかります。ページには、next.jsがレンダリングするには約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
next.jsの静的生成ページ（ getStaticProps ）よりも優れており、環境で1秒あたり2.5倍のリクエストを処理します。
next-boost 、レアルバリデートの場合にサーバー側のキャッシュを実装します。期限切れ（ stale ）ページにアクセスすると、キャッシュが提供され、同時にそのページの最新バージョン（ revalidate ）を取得し、キャッシュに保存します。
次の構成は、urisマッチング^/blog.* 。 next-boostによってページマッチrulesのみが処理され、 excludeルールはありません。
module . exports = {
rules : [ { regex : '^/blog.*' , ttl : 300 } ] ,
}キャッシュの動作を制御する2つのパラメーターがあります。
ttl (time-to-live) ： ttl秒後、キャッシュは再確認されます。また、キャッシュページのttl 、ページが再確認されたときに更新されます。tbd (time-before-deletion) ： ttl + tbd秒でページが再びヒットしない場合、キャッシュから完全に削除されます。上：URLを使用したキャッシュページのみが/blogから始まります。
Header x-next-boost:updateでGetを送信することにより、キャッシュが再確認されます。また、ページが存在しなくなった場合、キャッシュは削除されます。
$ curl -H x-next-boost:update https://the_server_name.com/path_aMutipleページを一度に削除する場合は、キャッシュで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、ワニスなど）を使用してリバースプロキシを使用します。HEADのみをGET 。worker_threadsが使用され、node.js 12+機能です。 next-boost next.jsのカスタムサーバー機能を使用することにより、 next startのインプレース交換として機能します。
上記のリンクページでは、次の通知を確認できます。
カスタムサーバーを使用することを決定する前に、next.jsの統合ルーターがアプリの要件を満たしていない場合にのみ使用する必要があることに留意してください。カスタムサーバーは、サーバーレス関数や自動静的最適化などの重要なパフォーマンスの最適化を削除します。
Next-BoostはクラウドVPSまたはコンテナで使用することを目的としているため、サーバーレス機能はここでは問題ではありません。 Automatic Static Optimizationに関しては、ここでapp.renderを実行していないため、いつものように完璧に機能します。
SQLiteを使用しない時期に関する記事は次のとおりです。そして、Next-Boostの主な純粋さについて：私の知る限り、それが最良の選択です。
mit。 Copyright 2020 Rakuraku Jyo。
