next boost

下一步

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+功能。

常见问题解答

请注意Next.js的自定义服务器

next-boost通过使用Next.js的自定义服务器功能，可作为next start的现场替代品。

在上面的链接页面上，您可以看到以下通知：

在决定使用自定义服务器之前，请记住，只有在Next.js的集成路由器无法满足您的应用程序要求时才能使用它。自定义服务器将删除重要的性能优化，例如无服务器功能和自动静态优化。

Next-Boost旨在在云VP或容器上使用，因此无服务器功能在这里不是问题。至于Automatic Static Optimization ，因为我们在这里没有进行任何app.render 。渲染程序仍然可以像往常一样完美。

为什么要sqlite

这是关于何时不使用SQLite的文章。据我所知，出于下一步助推器的主要目的：在低成本VPS上超级SSR，这是最好的选择。

执照

麻省理工学院。版权2020 Rakuraku Jyo。