next boost下載 - next boost源代碼下載

next boost

Ai源碼

Metrics support and cache status header

下載

下一步

next-boost將緩存層添加到您的SSR（服務器端渲染）應用程序中。它最初是為Next.js構建的，應使用基於http.server的任何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.js的生產模式： next start
大大降低服務器TTFB（首先字節）
用於緩存服務和使用worker_threads非阻滯主要過程
同時提出的第一個請求，其餘的請求來自緩存
小腳印，少於200個
在生產中使用30萬頁緩存
2個官方緩存適配器
- @Next-boost/redis-cache
  - 用於在集群中使用
  - 檢查.next-boost.redis.js以獲取示例配置
- @Next-Boost/Hybrid-Disk-Cache
  - 沒有內存容量限制，並且在便宜的VPS上效果很好
  - 出色的性能，甚至可能比純文件系統緩存更好
  - 主要平台上的可移植性
  - 檢查.next-boost.hdc.js以獲取示例配置

與Next.js一起使用`next-boost` CLI

安裝軟件包後，只需將開始腳本從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 PRERENDER和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

它甚至勝過Next.js的靜態生成的頁面（ getStaticProps ），在我的環境中處理2〜2.5倍的請求。

它如何工作

next-boost以陳舊的方式進行陳舊的方式實現服務器端緩存。當訪問過期的（ stale ）頁面時，將提供緩存，同時，背景過程將獲取該頁面的最新版本（ revalidate ）並將其保存到緩存中。

以下配置將緩存URIS匹配^/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 。

高級用法

刪除/重新驗證單個URL

通過使用標題x-next-boost:update到URL，將重新驗證緩存。如果頁面不再存在，將刪除緩存。

$ curl -H x-next-boost:update https://the_server_name.com/path_a

批處理刪除/重新驗證

如果要一次刪除Mutiple頁面，則可以直接在緩存上運行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更輕鬆地完成更複雜的規則。例如，您希望每個分頁頁面不同。

 // 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 Logic，您可以隨時在規則處理程序中匹配。

所有可配置的選項

如果有的話，將使用項目root的.next-boost.js 。如果您以編程方式使用Next-Boost，則可以將文件名更改為您傳遞給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 ，則可以通過將quiet布爾標誌作為CachedHandler的選項來禁用日誌。

...
const cached = await CachedHandler ( args , { quiet : true } ) ;
...

如果您使用的是命令行，也有一個--quiet標誌。

限制

對於具有多個負載平衡渲染服務器的體系結構，使用next-boost的好處是有限的。在每個後端服務器上擊中URL之前，它仍然可能會錯過緩存。為此，將反向代理（nginx，varnish等）使用。
僅GET和HEAD請求。
使用worker_threads ，它是一個node.js 12+功能。