这样加个中间件,接口速度提升 1000%

本文是在开发 mockm 周边过程中的创作。它可以快速生成 api 以及创造数据,开箱即用,便于部署,恳求不吝提出宝贵意见。

动机

最近在做一个 curd 项目,这里我们代名为 myApi ,用于实现 0 代码、无需声明模型、自动实现增删改查一些列的接口,支持任意关系型数据库。

经过几天的努力,终于把基本的 curd 实现了。但是性能如何呢?要知道,就是因为 json-server 的性能瓶颈太低,才创建此项目的。

json-server 使用 json 作为数据存储载体,当数据大于 10M 的时候,就触及了性能瓶颈,好在该库是用于原型开发,但如果要在生产环境使用,那等于埋了一个雷。

如何进行接口性能测试?

因为已经安装了 node,那就使用 autocannon ,它用于对 http/https 进行负载测试。

测试的结果如下图:

数据解释:

如何优化接口性能?

谈到优化,一般可以有很多个方向,例如业务逻辑、缓存,提升硬件配置等。

但是由于我们的 myApi 项目逻辑本就很简单,所以就先从缓存入手吧,因为经过分析,当前我们的项目是缺少缓存这一实现的。

缓存之 etag

ETag(Entity Tag)是一种由服务器生成的唯一标识符,用于表示资源的特定版本。服务器可以根据资源的内容、大小、最后修改时间等生成 ETag 值。当客户端请求资源时,服务器可以将 ETag 值包含在响应的头部中。客户端在后续请求中可以使用该 ETag 值来检查资源是否已经发生变化。

在 Express 中,我们可以使用 etag 中间件来启用 ETag 缓存。etag 中间件会自动处理 ETag 的生成和比较工作,并在响应头中添加相应的 ETag 值。

下面是一个示例代码,展示了如何在 Express 中使用 ETag 缓存:

javascript 复制代码
const express = require("express");
const app = express();
app.set("etag", true);

app.use(express.static("public")); // 静态资源目录

app.get("/api/data", (req, res) => {
  const data = {
    message: "Hello, World!",
  };
  res.json(data);
});

app.listen(3000, () => {
  console.log("Server started on port 3000");
});

在上述代码中,我们首先使用 express.static 中间件指定了一个静态资源目录 'public'。这意味着 Express 将自动处理位于 'public' 目录下的静态文件,并为它们生成 ETag 值。

然后,我们定义了一个路由 /api/data,用于返回一个 JSON 数据。在每个请求中,Express 会自动检查客户端请求的 ETag 值是否与服务器上的资源匹配。如果匹配,则服务器返回 304 Not Modified 状态码,表示客户端可以使用缓存的版本。如果不匹配,则服务器返回新的资源,并在响应头中添加新的 ETag 值。

ETag 的生成规则是响应体的简短唯一值,可以看成一个哈希值。观察上面的两张图片,第一次请求时,响应码是 200,并且返回了 Etag 。当下次请求的时候,会把该值带上,服务器会检查该值是否与之前的一致,如果一致,说明没有变化,返回 304,否则返回 200。

在 chrome 中发起几个接口请求:可以看到,第一次请求时数据为 1.6M,第二次为 214B,请求时间从 155ms 到 99ms 。这得到了以下提升:

  • 响应体减少了,在客户端网速很差的情况下,不用再次下载 1.6M 的数据。
  • 请求时间变快了,因为响应体没有变,服务器可以对客户端进行响应,再做后续逻辑。

缓存之 cache-control

然后从 cmd 控制台中可以看到,再次请求都有执行 sql。

虽然单个 sql 的查询速度通常在 几十到一百毫秒以内。但是为了实现多数据库兼容,我们使用了 ORM 框架,这有一定的转换成本,如果有复杂的业务逻辑存在,又加单次增加不少时间。在这几种叠加效果上,再加上并发的话,差异就会变成非常明显。

为了减少服务器压力,在数据没有变更的情况下,我们最好连业务逻辑相关的代码也不要执行。

那么问题就来了,我们怎么知道数据有没有变更呢?又如何为没有变更的数据进行缓存?

首先我们可以使用 http cache-control 对缓存进行精细化控制。

本文重点请几个属性,如果要了解更多信息,请在参考一节中查询相关文章。

在 Web 开发中,no-cachemax-age 是与缓存相关的 HTTP 头部指令,用于控制客户端和服务器之间的缓存行为。它们可以帮助我们更精确地管理缓存策略,以提高性能和资源利用率。

no-cache

no-cache 用于告诉客户端在使用缓存之前先与服务器确认资源是否已更改。当客户端收到带有 no-cache 指令的响应时,它将发送一个条件请求到服务器,以检查资源是否仍然有效。

服务器在收到条件请求后,可以执行一些验证逻辑,例如检查资源的最后修改日期或生成 ETag 值。如果资源未更改,服务器将返回 304 Not Modified 状态码,告知客户端可以使用缓存的版本。如果资源已更改,服务器将返回新的资源,并在响应头中添加新的缓存控制指令。

使用 no-cache 可以确保客户端始终与服务器进行验证,以获取最新的资源版本。这对于某些内容频繁更改的动态资源非常有用,但也会增加一定的网络开销。

max-age

max-age 用于指定资源在客户端缓存中的最大有效期。它表示从服务器发送响应后,客户端可以在指定的时间段内使用缓存的版本,而无需向服务器发出请求。

max-age 的值是以秒为单位的时间间隔。例如,max-age=3600 表示资源在客户端缓存中的有效期为 1 小时。当客户端再次请求相同的资源时,在 max-age 的时间范围内,客户端将直接使用缓存的版本,并避免向服务器发出请求。

使用 max-age 可以减少与服务器的通信次数,提高性能和响应速度。但请注意,这也可能导致客户端在有效期内使用过时的资源,因此需要根据资源的特性和更新频率进行适当的设置。

组合使用

no-cachemax-age 可以结合使用,以在客户端和服务器之间实现更细粒度的缓存控制。例如,可以使用 no-cache 确保客户端始终与服务器进行验证,但同时使用 max-age 设置一个相对较长的有效期,以减少与服务器的通信次数。

以下是一个示例响应头,演示了 no-cachemax-age 的组合使用:

ini 复制代码
Cache-Control: no-cache, max-age=3600

在上述示例中,响应头中同时包含了 no-cachemax-age 指令。这意味着客户端将始终与服务器进行验证,但在验证通过后,可以在 1 小时内使用缓存的版本。

通过合理地使用 no-cachemax-age,我们可以根据资源的特性和需求,灵活地控制缓存策略,从而提高应用程序的性能和用户体验。

总结

  • no-cache 指令告诉客户端在使用缓存之前先与服务器确认资源是否已更改。
  • max-age 指令指定资源在客户端缓存中的最大有效期。
  • no-cachemax-age 可以结合使用,以实现更精确的缓存控制策略。

缓存相关工具库

apicache

源码地址为 github.com/kwhitley/ap... ,共 1.2k stars,最近维护时间为 3 年前。对其尝试了下,默认情况下它会对所有路由进入缓存。这可以理解。

但是,在 myApi 中,当我首先调用 GET /api/book 获取所有书本列表,再调用 POST /api/book 创建一本书,这时 POST /api/book 的请求竟然会返回 /GET /api/book 的响应,这让我很意外。看进来默认情况下实现的是 path 级别的缓存,而不是 method + path 级别的缓存。

apicache 提供了一个选项 appendKey 用于自定义缓存的 key,应该是精细级别的控制。这个函数我没有测试过。

js 复制代码
apicache.options({
  appendKey: (req, res) => req.method + res.session.id,
});

还有另外一个选项叫缓存组,看起来像是我要的东西(我想缓存一个 table 表,如果表中任何数据更新,则此表的缓存也要更新):

js 复制代码
var apicache = require("apicache");
var cache = apicache.middleware;

// GET collection/id
app.get("/api/:collection/:id?", cache("1 hour"), function (req, res, next) {
  req.apicacheGroup = req.params.collection;
  // do some work
  res.send({ foo: "bar" });
});

// POST collection/id
app.post("/api/:collection/:id?", function (req, res, next) {
  // update model
  apicache.clear(req.params.collection);
  res.send("added a new item, so the cache has been cleared");
});

观察上面代码,/api/:collection 中的 :collection 类比表名,如果通过 POST /api/:collection 进行数据创建时,就调用 apicache.clear(req.params.collection) 清除 :collection 表的缓存。

可是经测试,结果还是不对。可能我的使用方式还不是太正确,但介于此库 3 年没有更新,以及我自身有一些想着反正都是根据逻辑来控制缓存策略,那好像和自己写一个缓存器也没什么区别,对于此工具提供的 redis 支持,在 myApi 里是不需要的。所以没有继续探究问题出在哪里。

lru-cache

star 高达 5k,npm 周使用量 185,936,796 。这是一个基于访问频率进入缓存保留的库。即那些不常用的缓存会先被删除。

@isaacs/ttlcache

这是一个基于时间的缓存库,最先到期的缓存会最先被删除。

选择和应用

在我的用例中,我认为基于时间的缓存策略对于我来说是更好的选择。所以我选择了 @isaacs/ttlcache

js 复制代码
const TTLCache = require("@isaacs/ttlcache");
const cacheStore = {};
function cacheFn(config) {
  return (req, res, next) => {
    const method = req.method.toLowerCase();
    const query = Object.keys(req.query).length ? req.query : ``;
    const { table = ``, id = `` } = req.params;
    const cacheTable = (cacheStore[table] =
      cacheStore[table] || new TTLCache({ max: 10000, ttl: 1e3 * 10 })); // 表级别的缓存
    if (method === `get`) {
      const disableCache = req.headers["cache-control"] === `no-cache`;
      const reqKey = generateMD5(
        [method, table, id, JSON.stringify(query)].join(``)
      );
      const etag = req.headers["if-none-match"];
      console.log({ reqKey, etag });
      // 禁用缓存时,获取最新数据,并刷新缓存,这样在开启缓存时会直接命中缓存
      if (disableCache) {
        cacheTable.set(reqKey, true);
        next();
      } else if (!cacheTable.get(reqKey)) {
        // 缓存失效时,获取最新数据并刷新缓存
        cacheTable.set(reqKey, true);
        next();
      } else if (cacheTable.get(reqKey)) {
        // 缓存有效时,告诉浏览器缓存可用
        res.setHeader("Cache-Control", "no-cache");
        res.status(304).end();
      } else {
        next();
      }
    } else {
      cacheTable.clear();
      next();
    }
    console.log(cacheStore);
  };
}

这段代码的主要功能是根据请求的不同情况来处理缓存。

  1. 在每个请求中,根据请求的方法、表名、ID 和查询参数生成一个唯一的请求键 reqKey
  2. 如果请求方法是 GET
    • 检查请求头中是否包含 cache-control: no-cache 指令,如果是,则禁用缓存,获取最新数据,并刷新缓存。
    • 如果缓存失效(即 reqKey 在缓存中不存在),则获取最新数据,并刷新缓存。
    • 如果缓存有效(即 reqKey 在缓存中存在),则设置响应头 Cache-Control: no-cache,并返回 304 Not Modified 状态码,告知浏览器可以使用缓存。
    • 如果以上条件都不满足,则继续处理下一个中间件或路由处理程序。
  3. 如果请求方法不是 GET,则清除缓存,并继续处理下一个中间件或路由处理程序。
  4. 在每个请求结束后,打印缓存存储对象 cacheStore

使用该插件后的测试效果为: 100 并发 800ms 左右

额外的思考和行动

在上面的代码中,可以看到我们为每个 table 实现了一个缓存实例。在实例中每个 table 下的 api 是缓存的子项,如果子项有更新,则缓存实例会更新。而所有的实例都保存在 cacheStore 这个对象中。这样看来,@isaacs/ttlcache 这个库似乎最大的作用就是用来管理缓存总数、过期时间,提供了一些简单的 get set clear 方法而已?那我尝试弄一个看看,这样又可以少引用一个库了?

首先,反正大家都是内存缓存,那直接把状态保存在公用对象中即可。另外,过期时间和缓存大小这些通过 Date.now() 对比,数组 length 对比这些好像就能搞定。试试看:

js 复制代码
class TTLCache {
  options = {
    ttl: 60 * 60 * 1e3, // 缓存过期时间
    max: 10 * 1e3, // 最大缓存数量
  };
  store = {}; // 保存的 key 缓存状态
  constructor(options) {
    this.options = Object.assign(this.options, options);
    setInterval(() => {
      const list = Object.entries(this.store);
      list.map(([key, val], index) => {
        if (
          index < this.options.max || // 溢出的缓存
          Date.now() - val < this.options.ttl // 过期的缓存
        ) {
          delete this.store[key];
        }
      });
    }, this.options.ttl);
    return this;
  }
  get(key) {
    const old = this.store[key];
    return old ? Date.now() - old < this.options.ttl : false;
  }
  set(key) {
    this.store[key] = Date.now();
  }
  clear() {
    this.store = {};
  }
}

经尝试,使用自己实现的缓存器,减少 60% 以上的时间,从 800ms 到 320ms。为了保证内存占用不高,定时根据 max 配置裁剪缓存数量和过期的缓存。

去除 console 后,大约每秒处理 1400 个请求,5 秒处理完 7000 个请求,并发数为 200,平均每个接口用时 70ms。

store 对象的值如下:

js 复制代码
store = {
  "651b10c00298624a5b61053c6d970f7c": 1706627825171,
  "d980f49196fce9d6d1fd41557c8ed9da": 1706627825353,
  "34260c615ac67e948250222b0a506136": 1706627825367,
};

乍一看,性能好像是提升了不少,但其实是有很多需要完善的地方的,例如:定时器的执行时间是 ttl 的设置时间,假如 ttl 为 1 小时,那么在这 1 小时内,是不会触发缓存数量裁剪的,在特殊情况下这会导致内存增加。

不过,就一个 hash 和时间,这应该也要不了多少内存(如果存储的时间是应用启动时间到当前时间的差,并且使用 etag 的计算方式,可能还会减少很多内存)。所以我就先使用自己的这段代码吧(应该 ttlcache/lru-cache 他们有更完善的实现,例如内存限制等)。

总结

  • etag:服务器读取真实数据做比较,如果相同则不发送真实数据。
  • cache:服务器不读取真实数据,而是返回上次请求中的数据或返回未变更标志。
  • 难点:判断某请求是否为同一请求,例如相同的请求参数和身份。
  • 注意:浏览器不使用缓存时,就算服务器发送未变更标记,浏览器也不从缓存读取数据,而是从服务器读取数据,这时要求服务器必须要发送数据。
  • 结果:从并发 100 avg 800ms 到并发 200 avg 70ms 应该有提升 1000% 的吧。
  • 逃:前端是产品形态差异很大的平台,不谈应用场景都是耍流氓。

相关文章

本文是在开发 mockm 周边过程中的创作。它可以快速生成 api 以及创造数据,开箱即用,便于部署,恳求不吝提出宝贵意见。

相关推荐
paopaokaka_luck2 小时前
【360】基于springboot的志愿服务管理系统
java·spring boot·后端·spring·毕业设计
逐·風3 小时前
unity关于自定义渲染、内存管理、性能调优、复杂物理模拟、并行计算以及插件开发
前端·unity·c#
Devil枫3 小时前
Vue 3 单元测试与E2E测试
前端·vue.js·单元测试
码农小旋风3 小时前
详解K8S--声明式API
后端
Peter_chq3 小时前
【操作系统】基于环形队列的生产消费模型
linux·c语言·开发语言·c++·后端
Yaml44 小时前
Spring Boot 与 Vue 共筑二手书籍交易卓越平台
java·spring boot·后端·mysql·spring·vue·二手书籍
小小小妮子~4 小时前
Spring Boot详解:从入门到精通
java·spring boot·后端
hong1616884 小时前
Spring Boot中实现多数据源连接和切换的方案
java·spring boot·后端
尚梦4 小时前
uni-app 封装刘海状态栏(适用小程序, h5, 头条小程序)
前端·小程序·uni-app
GIS程序媛—椰子4 小时前
【Vue 全家桶】6、vue-router 路由(更新中)
前端·vue.js