next boost
Metrics support and cache status header
next-boost menambahkan lapisan cache ke aplikasi SSR (server-side rendering) Anda. Awalnya dibangun untuk Next.js dan harus bekerja dengan aplikasi berbasis node.js http.Server apa pun.
next-boost mencapai kinerja yang hebat dengan memberikan halaman web di worker_threads sambil menyajikan cache di utas utama.
Jika Anda terbiasa dengan Next.js , next-boost dapat dianggap sebagai implementasi regenerasi statis tambahan yang bekerja dengan getServerSideProps . Dan itu tidak dimaksudkan untuk digunakan dengan getStaticProps , di mana Next.js akan melakukan cache untuk Anda.
$ 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 untuk SSR.next-boost.redis.js untuk konfigurasi sampel.next-boost.hdc.js untuk konfigurasi sampel next-boost dengan Next.js Setelah menginstal paket, cukup ubah skrip Mulai dari next start ke next-boost . Semua argumen baris perintah next start , seperti -p untuk menentukan port, kompatibel.
"scripts": {
...
"start": "next-boost", // previously `next start`
...
},
Ada contoh di bawah examples/nodejs , yang berfungsi dengan http.Server polos.
Untuk menggunakannya dengan express.js dan next.js , silakan periksa examples/with-express .
Dengan menggunakan worker_threads , render SSR CPU-berat tidak akan menghalangi proses utama dari melayani cache.
Berikut adalah perbandingan menggunakan ApacheBench pada posting blog yang diambil dari database. HTML Prerendered dan operasi DB membutuhkan waktu sekitar 10 ~ 20ms. Halaman ini membutuhkan waktu sekitar 200 ms untuk render berikutnya.
$ /usr/local/bin/ab -n 200 -c 8 http://127.0.0.1:3000/blog/posts/2020/3/postnameBukan tolok ukur ilmiah, tetapi perbaikannya tampak sangat besar.
dengan next start (data diambil dengan 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
dengan drop-in 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
Bahkan mengungguli halaman yang dihasilkan statis ( getStaticProps ) Next.js, menangani 2 ~ 2.5x permintaan per detik di lingkungan saya.
next-boost mengimplementasikan cache sisi server dengan cara basi-ketika-revalidasi. Ketika halaman yang kedaluwarsa ( stale ) diakses, cache akan disajikan dan pada saat yang sama, proses latar belakang akan mengambil versi terbaru ( revalidate ) dari halaman itu dan menyimpannya ke cache.
Konfigurasi berikut akan mencocokkan Pencocokan URI ^/blog.* . Hanya rules pencocokan halaman yang akan ditangani oleh next-boost dan tidak ada aturan exclude .
module . exports = {
rules : [ { regex : '^/blog.*' , ttl : 300 } ] ,
}Ada 2 parameter untuk mengontrol perilaku cache:
ttl (time-to-live) : Setelah ttl detik, cache akan divalidasi ulang. Dan ttl halaman yang di -cache akan diperbarui ketika halaman divalidasi.tbd (time-before-deletion) : Ketika halaman tidak dipukul lagi di ttl + tbd detik, itu akan sepenuhnya dihapus dari cache. Atas: Hanya halaman caching dengan URL mulai dengan /blog .
Dengan mengirimkan header x-next-boost:update ke URL, cache akan divalidasi ulang. Dan jika halaman tidak ada lagi, cache akan dihapus.
$ curl -H x-next-boost:update https://the_server_name.com/path_aJika Anda ingin menghapus halaman mutiple sekaligus, Anda dapat menjalankan SQL pada cache secara langsung:
sqlite3 /cache_path/cache.db " update cache set ttl=0 where key like '%/url/a%'; " Ini akan memaksa semua URL yang mengandung /url/a untuk diakses kembali ketika diakses waktu berikutnya.
Menghapus cache_path akan menghapus semua cache.
Secara default, setiap halaman dengan URL yang berbeda akan di -cache secara terpisah. Tetapi dalam beberapa kasus yang Anda inginkan, /path_a?utm_source=twitter untuk dilayani dengan konten /path_a yang sama. paramFilter adalah untuk memfilter parameter kueri.
// in .next-boost.js
{
...
paramFilter : ( p ) = > p !== 'utm_source'
}Secara default, URL akan digunakan sebagai kunci untuk halaman yang di -cache. Jika Anda ingin ke halaman server dari domain yang berbeda atau dengan agen pengguna yang berbeda, Anda dapat menggunakan fungsi ini untuk menyesuaikan kunci cache.
Catatan:
string , server Anda akan macet. // in .next-boost.js
{
...
cacheKey : ( req ) = > ( req . headers . host || '' ) + ':' + req . url
}Atau Anda dapat memberikan fungsi alih -alih array di dalam konfigurasi Anda.
// in .next-boost.js
{
...
rules : ( req ) = > {
if ( req . url . startsWith ( '/blog' ) ) {
return 300
}
}
} Fungsi harus mengembalikan ttl yang valid untuk permintaan tersebut. Jika fungsi mengembalikan 0 atau nilai falsy , permintaan tidak akan di -cache.
Kekuatan yang berasal dari metode ini adalah Anda dapat memutuskan apakah permintaan tersebut di -cache atau tidak lebih dinamis.
Misalnya Anda dapat secara otomatis mengabaikan semua permintaan dari pengguna yang diautentikasi berdasarkan header:
// in .next-boost.js
{
...
rules : ( req ) = > {
if ( req . headers . authorization ) {
return false
}
return 10 // cache all other requests for 10 seconds
}
}Anda juga bisa menyelesaikan aturan yang lebih kompleks lebih mudah daripada Regex. Misalnya Anda berharap TTL yang berbeda untuk masing -masing halaman pagination.
// 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
}
}Meskipun Anda perlu menulis aturan Regex yang kompleks atau berpotensi lebih banyak aturan, mudah dilakukan melalui logika JS.
Pada akhirnya jika Anda lebih suka menulis Regex tetapi ingin memanfaatkan logika JS Anda selalu dapat mencocokkan Regex di dalam aturan penangan.
Jika tersedia, .next-boost.js di root proyek akan digunakan. Jika Anda menggunakan boost berikutnya secara terprogram, nama file dapat diubah dalam opsi yang Anda lewati ke CachedHandler .
Kiat: Jika Anda menggunakan CLI next-boost dengan Next.js, Anda mungkin ingin menggunakan file config.
Dan inilah contoh .next-boost.sample.js dalam repo.
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 Logging diaktifkan secara default. Jika Anda menggunakan next-boost secara terprogram, Anda dapat menonaktifkan log dengan melewati bendera boolean quiet sebagai opsi untuk CachedHandler .
...
const cached = await CachedHandler ( args , { quiet : true } ) ;
... Ada juga -bendera --quiet jika Anda menggunakan baris perintah.
next-boost terbatas. Sampai URL dipukul di setiap server backend, ia masih bisa kehilangan cache. Gunakan proxy terbalik dengan dukungan cache (nginx, varnish dll) untuk itu.GET dan hanya permintaan HEAD .worker_threads digunakan dan ini adalah fitur Node.js 12+. next-boost berfungsi sebagai pengganti di tempat untuk next start dengan menggunakan fitur server kustom Next.js.
Pada halaman yang ditautkan di atas, Anda dapat melihat pemberitahuan berikut:
Sebelum memutuskan untuk menggunakan server khusus, harap diingat bahwa itu hanya boleh digunakan ketika router terintegrasi Next.js tidak dapat memenuhi persyaratan aplikasi Anda. Server khusus akan menghapus optimasi kinerja yang penting, seperti fungsi tanpa server dan optimasi statis otomatis.
Next-boost dimaksudkan untuk digunakan pada VP cloud atau wadah, sehingga fungsi tanpa server tidak menjadi masalah di sini. Mengenai Automatic Static Optimization , karena kami tidak melakukan app.render di sini, masih berfungsi, sempurna seperti biasa.
Inilah artikel tentang kapan tidak menggunakan sqlite. Dan untuk tujuan utama Boost berikutnya: SSR super lebih cepat pada VPS berbiaya rendah, sejauh yang saya tahu, itu adalah pilihan terbaik.
Mit. Hak Cipta 2020 Rakuraku Jyo.
