如何对API进行负载测试与调优（一）

Posted 2023-04-16

参考技术A 本文由Donny译自 3scale.com 的 《How to load test & tune performance on your API》

这几年API的作用不断演化，以前API还只是用来做内部系统之间的集成点，但现在API已成为一个公司的核心系统，一个构建于Web和移动端应用之上的核心系统。

当API仅只用来处理后台的任务（例如生成报告），那么性能差点也不是问题。但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。这种关键性的角色变化表明了一个重要的观点：那就是API的性能真的很重要。

如果API数据源响应快，前端的应用程序的设计好点或差点影响不大，要是响应慢如蜗牛，前端的设计再出色也是然并卵。现在我们的客户端应用展示的数据源可能都是来自多个API响应内容的聚合，性能对这种微服务构架来说真的非常重要。

可以毫不夸张的说出色的性能就是你API提供的最好功能。我们知道向目标改进的唯一正确的方法就是找到问题的关键点，或者叫关键路径，并不断迭代测量和调整你的架构系统，直到系统达到预定的目标。对于API来说，测量和提高性能的过程就是负载与压力测试的过程。

本文将重点介绍如何对你的API进行负载压力测试。我们会以一个简单的、未测过的例子开始，然后再添加一个访问控制层，要确保一切都经过严格测试，做好处理真实流量的准备工作。OK，开始吧！

首先我们要明确要测试什么，可以是对你所有的API接口，或者是对单个API接口，或是对需要排除故障或改进的API接口的常规测试。

本文的其部分，我们将使用一个示例API。这是一个棋牌类游戏的Node.js API。它有三个API接口：

/question – 返回一个随机黑牌

/answer – 返回一个随机白牌

/pick – 返回一对随机的问题与答案

你测试用的负荷情况越和真实环境的越类似，你的负载测试就越有用。如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致，那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。

所以，你应该先从收集你API的使用数据开始。你可以直接从你的API服务日志或者从其他你在用的应用性能工具（例如New Relic）中获取数据。在对你的API进行第一次测试之前，你应该对以下问题做到心中有数：

（1）每秒请求数的平均吞吐量（Average throughput in requests per second）

（2）峰值吞吐量（您在某段时间内获得的最大流量是多少？）（Peak throughput）

（3）API各接口的吞吐量分布情况（有没有一些接口的流量远超其他接口？）

（4）用户的吞吐量分布情况（少数用户产生大多数的流量，或者是更均匀分布？）

另外还需要考虑的一个关键点是，在测试期间将要模拟的流量会是怎样的，主要考虑点是：

（1）重复负载生成（Repetitive load generation）

（2）模拟流量模式

（3）真实流量

通常我们最好以最简单的方法开始测试，然后逐步演化到更为接近真实环境的测试。我们可以先用重复负载生成来做为API接口的第一个测试，这样不仅可以验证我们的测试环境是否稳定，更重要的是可以让我们找到API能承受的最大吞吐量，这样我们就可以知道API可以达到的性能上限是多少。

找到你的API性能上限值后，你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。使用真实流量来测试是最理想的，但实际操作不太可行。要模拟真实流量比较难，也太花时间。所以我们有一个折中点的方法：先研究你的流量分析数据，并做一个简单的概率模拟。比如你有100个API接口（提示：原文endpoint在这里我译为接口，翻译成端点也可以，不过译成接口感觉更容易理解），你检查了上个月的使用情况，发现80%的流量来自20个接口，其中3个接口占用了50%的流量。那么你就可以创建一个遵循这种概率的请求列表，并提供给你的负载测试工具。这样做就相对快多了，并且它相对比较接近你真实负载，可以显示出你实际环境中可能遇到的问题。

最后，如果你拿到你要测试的API的真实访问日志，你就可以用它们来做最接近客观现实的测试。我们待会儿要讨论的大部分负载测试工具，都是接收一个请求列表作为输入文件。你可以用你的访问日志，稍微做一个格式调整就可以匹配每个测试工具所需的格式。搞定这个你就可以在测试环境中轻松重现你的生产流量。

好了，你清楚了你要测试什么鬼了，准备工作的最后一步就是配置好你的测试环境。你需要一个专用的测试环境。如果你不怕被你老板骂的话，或者比较任性，你也可以直接在你的生产环境中进行性能测试，不过出问题别说哥事先没跟你说清楚哈。

如果您已经设好一个预生产或沙箱环境，并且你的API也在上面运行了，那么你就万事俱备了。因为本文要用示例API，我们会在AWS的服务实例上设置我们的环境。

在我们的例子中，我们使用一个简单的API，不需要从磁盘读取或在内存中保存大型数据集。我们选择Linux C4.large 实例就够了。

注意：我们对比过其他相似处理资源数但内存更大的AWS实例，但实际测试中内存大部分没使用，所以我们选了C4.large

接下来，我们将一个配好的负载测试实例（服务器）运行起来，这只是一个运行模拟测试程序的服务器，它会通过从多个并发连接重复发送请求到我们的API服务器。你需要模拟的负载越高，机器的性能就要求越高。再次，这也是一个CPU密集型工作负载。这里我们选择具有4个虚拟核，16个 ECU的优化处理器的 c4.xlarge AWS服务器

我们选择在相同的可用区内部署所有实例（API服务器与测试服务器在同一个区/机房），这样可以将外部因素对我们测试结果的影响降到最小。

我们有一个沙箱环境来运行我们的API，同时也有另一台服务器准备开始负载测试。如果这是你第一次做性能测试，你一定会想知道什么是最好的方法。在本节中，我们将会分享我们如何选择工具，同时也会介绍一下目前市面上一些公认比较好的工具。

JMeter

在人们意识当中，首当翘楚的估计是 Apache JMeter ，这是一个开源的Java程序，他关键的特性就是提供一个强大而完善的创建测试计划的GUI。测试计划由测试组件组成，测试组件定义了测试的每一个部分，例如：

（1）用来注入负载测试的线程

（2）参数化测试中使用的HTTP请求

（3）可添加侦听器，象widget测试组件那样，可以以不同的方式显示测主式结果

优点：

（1）它是功能性负载测试的最好工具。你可以设定条件来为复杂的用户流建模，还可以创建断言来验证行为。

（2）轻松模拟复杂的http请求，比如请求前的登录验证或文件上传

（3）可扩展性强，有很多社区插件可以修改或扩展内置的行为

（4）开源并且免费

缺点：

（1）GUI学习曲线陡峭，一大堆的选项，在你运行第一个测试之前你得了解大量的概念。

（2）测试高负载时，操作步骤很麻烦。你需要先使用GUI工具来生成XML测试计划，然后在非GUI模式下导入测试计划运行测试，因为GUI会消耗掉本用于生成负载的大量资源。你还需要注意所有的侦听器（收集数据与展示测量的组件）哪些要被禁用或启用，因为它们也很耗资源。测试结束后后，你需要将原始结果数据导入GUI以才能查看结果。

（3）如果你的目标是测试一段时间内的持续吞吐量（例如在60秒内每秒请求1000次），那么很难找到正确的并发线程数量和计时器来求出一个比较稳定的数值。

JMeter只是我们在开始测试时用的工具，我们很快开始寻找其他替代方案。原因是，如果你的目标是在Web应用上压力测试复杂的用户流，那么JMeter可能是最好的工具，但如果你只是需要在一些HTTP API接口上进行性能测试，那用它就是杀鸡用牛刀了。

Wrk

Wrk 是一款和传统的 Apache Benchmark （最初用来做Apache服务器的测试工具）非常相似的工具。wrk和ab完全不同于JMeter：

（1）一切都是可以通过命令行工具配置和执行的。

（2）配置少但强大，只有基本生成HTTP负载的必要几项配置

（3）性能强悍

然而，和传统ab工具相比还是有几个优势的地方，主要是：

（1）多线程，所以能利用多核处理器的优势，更容易生成更高的负载

（2）利用Lua脚本很容易进行扩展默认的行为

不好的地方，主要是生成的默认报告在内容与格式上都受到限制（仅文本，无绘图）。当你的目标是找到你的API可以处理的最大负载量，那么wrk是你最佳选择工具。wrk用起来很快就可以上手。

Vegeta

Vegeta 是一款开源命令行工具，但它采用的方式不同于我们以前所见的工具。它专注于如何达到与维持每秒请求数速率。也就是说它侧重在测试支撑每秒X次请求时API会有怎样的服务行为，当你有实际的数据或对你将要达到的峰值流量有个估算时就非常有用，你可以用于验证你的API是否能满足你的需求。

SaaS 工具

正如你之前所看到的，运行一个简单的负载测试需要准备好配置环境。最近有些产品提供负载测试服务。我们试过两个， Loader.io 和 Blazemeter （话外：阿里也有性能测试工具 PTS ，老外估计没试过）。

注意：我们只试了这两个工具的免费版，所以得到的测试结果仅适用于免费版的限定。

Blazemeter

这个产品和我们前面提到的JMeter一样有同样的毛病：如果你只需要用在高负载测试，你需要在GUI界面上创建测试计划，然后在另一个运行非GUI模式的JMeter中导入这些计划。Blazemeter允许你上传JMeter的测试计划到他们的云端并运行，但可惜的是免费版只能设置50个并发用户。

Loader.io

它是一款 SendGrid 出品的简单而强大的云负载测试服务工具。它有你所需要的功能和漂亮的可视报告。 Loader.io 的免费版还是不错的，每秒最多可以有10000次请求的吞吐量，你基本上就可以用它来运行一个真实的负载测试。

我们推荐使用多个工具，以便可以多重检查我们的测试结果，不同的工具有不同的功能与方法，可以更多方面地反映测试结果。

我们先尝试找到我们的API可以承受的最大吞吐量。在这个吞吐量下，我们的API服务达到最大CPU利用率，同时不会返回任何错误或超时。这个吞吐量就可作为我们后面测试要用的每秒请求数。

同样，重要的是要注意到：CPU是限制因素之一，但你也还必须清楚地知道哪些资源会成为你API的性能瓶颈。

我们有必要在API服务器上安装一些工具，以便我们在测试过程中监控资源的利用率情况。我们使用  Keymetrics.io  和  PM2  模块。

我们的Node.js应用运行了一个非常简单的HTTP 服务。Node.js是单线程设计的，但为了利用c4.large AWS实例中提供的双核，我们使用PM2的集群功能来运行应用程序的两个工作进程。

由于我们的API是完全无状态的，所以很容易使用PM2的 核心集群模块（PM2在内部直接使用）。PM2提供的集群功能提供了不错的快捷命令来start/stop/reload应用程序，也可以监控进程。

我们先使用Loader.io对API进行测试。以下是持续30秒，每秒10,000次请求的测试结果，10000次请求是Loader.io免费版中允许的最大吞吐量。

在测试期间，我们观察到API服务器的CPU处理器在测试期间只有几次达到100％的容量。

这表示我们的API可能还可以处理更高的吞吐量。我们接下来通过运行wrk进行第二次测试证实了这一点。我们的目标就是要将我们的API服务器性能推到极限。

wrk -t 4 -c 1000 -d 60 --latency --timeout 3s http://api-server/questions

这里是我们对这个测试做了多次重复测试的结果：

Running 1m test @ http://api-server/question

4 threads and 1000 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 62.23ms 30.85ms 1.35s 99.39%

Req/Sec 4.07k 357.61 5.27k 94.29%

Latency Distribution

50% 60.04ms

75% 63.85ms

90% 64.17ms

99% 75.86ms

972482 requests in 1.00m, 189.89MB read

Requests/sec: 16206.04

Transfer/sec: 3.16MB

结果表明，我们的预感被证实：它达到16,206请求/秒，同时保持合理的延迟，第99百分位只有75.86毫秒。 我们将这作为我们的基准最大吞吐量，因为这一次我们看到了API服务器的最大容量处理能力：

我们刚看到用一个简单的方式来找出你的API可承受的最大流量负载，同时在这过程中我们介绍并讨论了我们看到的一些工具。

请继续关注本文的第二部分，我们将介绍如何控制流量，不要让随随便便一个客户端就可以轻松搞跨您的API。 我们将展示如何通过在架构前端添加代理来确保我们的API的性能不受影响。

本文译自： How to load test & tune performance on your API

etcd 性能测试与调优

etcd 是一个分布式一致性键值存储。其主要功能有服务注册与发现、消息发布与订阅、负载均衡、分布式通知与协调、分布式锁、分布式队列、集群监控与 leader 选举等。

1.etcd 性能优化

官方文档原文：https://github.com/etcd-io/etcd/blob/master/Documentation/tuning.md 译文参考：https://skyao.gitbooks.io/learning-etcd3/content/documentation/op-guide/performance.html

理解 etcd 的性能

决定 etcd 性能的关键因素，包括：

• 延迟 (latency)：延迟是完成操作的时间。
• 吞吐量 (throughput)：吞吐量是在某个时间期间之内完成操作的总数量。当 etcd 接收并发客户端请求时，通常平均延迟随着总体吞吐量增加而增加。

在通常的云环境，比如 Google Compute Engine (GCE) 标准的 n-4 或者 AWS 上相当的机器类型，一个三成员 etcd 集群在轻负载下可以在低于 1 毫秒内完成一个请求，并在重负载下可以每秒完成超过 30000 个请求。

etcd 使用 Raft 一致性算法来在成员之间复制请求并达成一致。一致性性能，特别是提交延迟，受限于两个物理约束：网络 IO 延迟和磁盘 IO 延迟。完成一个 etcd 请求的最小时间是成员之间的网络往返时延 (Round Trip Time / RTT)，加需要提交数据到持久化存储的 fdatasync 时间。在一个数据中心内的 RTT 可能有数百毫秒。在美国典型的 RTT 是大概 50ms, 而在大陆之间可以慢到 400ms。旋转硬盘(注：指传统机械硬盘) 的典型 fdatasync 延迟是大概 10ms。对于 SSD 硬盘, 延迟通常低于 1ms。为了提高吞吐量, etcd 将多个请求打包在一起并提交给 Raft。这个批量策略让 etcd 在重负载试获得高吞吐量。也有其他子系统影响到 etcd 的整体性能。每个序列化的 etcd 请求必须通过 etcd 的 boltdb 支持的(boltdb-backed) MVCC 存储引擎, 它通常需要 10 微秒来完成。etcd 定期递增快照它最近实施的请求，将他们和之前在磁盘上的快照合并。这个过程可能导致延迟尖峰(latency spike)。虽然在 SSD 上这通常不是问题，在 HDD 上它可能加倍可观察到的延迟。而且，进行中的压缩可以影响 etcd 的性能。幸运的是，压缩通常无足轻重，因为压缩是错开的，因此它不和常规请求竞争资源。RPC 系统，gRPC，为 etcd 提供定义良好，可扩展的 API，但是它也引入了额外的延迟，尤其是本地读取。

Etcd 的默认配置在本地网络环境（localhost）下通常能够运行的很好，因为延迟很低。然而，当跨数据中心部署 Etcd 或网络延时很高时，etcd 的心跳间隔或选举超时时间等参数需要根据实际情况进行调整。

网络并不是导致延时的唯一来源。不论是 Follower 还是 Leader，其请求和响应都受磁盘 I/O 延时的影响。每个 timeout 都代表从请求发起到成功返回响应的总时间。

时间参数

Etcd 底层的分布式一致性协议依赖两个时间参数来保证节点之间能够在部分节点掉钱的情况下依然能够正确处理主节点的选举。第一个参数就是所谓的心跳间隔，即主节点通知从节点它还是领导者的频率。实践数据表明，该参数应该设置成节点之间 RTT 的时间。Etcd 的心跳间隔默认是 100 毫秒。第二个参数是选举超时时间，即从节点等待多久没收到主节点的心跳就尝试去竞选领导者。Etcd 的选举超时时间默认是 1000 毫秒。

调整这些参数值是有条件的，此消波长。心跳间隔值推荐设置为临近节点间 RTT 的最大值，通常是 0.5~1.5 倍 RTT 值。如果心跳间隔设得太短，那么 Etcd 就会发送没必要的心跳信息，从而增加 CPU 和网络资源的消耗；如果设得太长，就会导致选举等待时间的超时。如果选举等待时间设置的过长，就会导致节点异常检测时间过长。评估 RTT 值的最简单的方法是使用 ping 的操作。

选举超时时间应该基于心跳间隔和节点之间的平均 RTT 值。选举超时必须至少是 RTT 10 倍的时间以便对网络波动。例如，如果 RTT 的值是 10 毫秒，那么选举超时时间必须至少是 100 毫秒。选举超时时间的上线是 50000 毫秒（50 秒），这个时间只能只用于全球范围内分布式部署的 Etcd 集群。美国大陆的一个 RTT 的合理时间大约是 130 毫秒，美国和日本的 RTT 大约是 350~400 毫秒。如果算上网络波动和重试的时间，那么 5 秒是一次全球 RTT 的安全上线。因为选举超时时间应该是心跳包广播时间的 10 倍，所以 50 秒的选举超时时间是全局分布式部署 Etcd 的合理上线值。

心跳间隔和选举超时时间的值对同一个 Etcd 集群的所有节点都生效，如果各个节点都不同的话，就会导致集群发生不可预知的不稳定性。Etcd 启动时通过传入启动参数或环境变量覆盖默认值，单位是毫秒。示例代码具体如下：

$ etcd --heartbeat-interval=100 --election-timeout=500

# 环境变量值
$ ETCD_HEARTBEAT_INTERVAL=100 ETCD_ELECTION_TIMEOUT=500 etcd

快照

Etcd 总是向日志文件中追加 key，这样一来，日志文件会随着 key 的改动而线性增长。当 Etcd 集群使用较少时，保存完整的日志历史记录是没问题的，但如果 Etcd 集群规模比较大时，那么集群就会携带很大的日志文件。为了避免携带庞大的日志文件，Etcd 需要做周期性的快照。快照提供了一种通过保存系统的当前状态并移除旧日志文件的方式来压缩日志文件。

快照调优

为 v2 后端存储创建快照的代价是很高的，所以只用当参数累积到一定的数量时，Etcd 才会创建快照文件。默认情况下，修改数量达到 10000 时才会建立快照。如果 Etcd 的内存使用和磁盘使用过高，那么应该尝试调低快照触发的阈值，具体请参考如下命令。

启动参数：

$ etcd --snapshot-count=5000

环境变量：

$ ETCD_SNAPSHOT_COUNT=5000 etcd

磁盘

etcd 的存储目录分为 snapshot 和 wal，他们写入的方式是不同的，snapshot 是内存直接 dump file。而 wal 是顺序追加写，对于这两种方式系统调优的方式是不同的，snapshot 可以通过增加 io 平滑写来提高磁盘 io 能力，而 wal 可以通过降低 pagecache 的方式提前写入时序。因此对于不同的场景，可以考虑将 snap 与 wal 进行分盘，放在两块 SSD 盘上，提高整体的 IO 效率，这种方式可以提升 etcd 20% 左右的性能。

etcd 集群对磁盘 I/O 的延时非常敏感，因为 Etcd 必须持久化它的日志，当其他 I/O 密集型的进程也在占用磁盘 I/O 的带宽时，就会导致 fsync 时延非常高。这将导致 Etcd 丢失心跳包、请求超时或暂时性的 Leader 丢失。这时可以适当为 Etcd 服务赋予更高的磁盘 I/O 权限，让 Etcd 更稳定的运行。在 Linux 系统中，磁盘 I/O 权限可以通过 ionice 命令进行调整。

nux 默认 IO 调度器使用 CFQ 调度算法，支持用 ionice 命令为程序指定 IO 调度策略和优先级，IO 调度策略分为三种：

• Idle ：其他进程没有磁盘 IO 时，才进行磁盘 IO
• Best Effort：缺省调度策略，可以设置 0-7 的优先级，数值越小优先级越高，同优先级的进程采用 round-robin 算法调度；
• Real Time ：立即访问磁盘，无视其它进程 IO
• None 即 Best Effort，进程未指定策略和优先级时显示为 none，会使用依据 cpu nice 设置计算出优先级

Linux 中 etcd 的磁盘优先级可以使用 ionice 配置：

$ ionice -c2 -n0 -p `pgrep etcd`

网络

etcd 中比较复杂的是网络的调优，因此大量的网络请求会在 peer 节点之间转发，而且整体网络吞吐也很大，但是还是再次强调不建议大家调整系统参数，大家可以通过修改 etcd 的 --heartbeat-interval 与 --election-timeout 启动参数来适当提高高吞吐网络下 etcd 的集群鲁棒性，通常同步吞吐在 100MB 左右的集群可以考虑将 --heartbeat-interval 设置为 300ms-500ms，--election-timeout 可以设置在 5000ms 左右。此外官方还有基于 TC 的网络优先传输方案，也是一个比较适用的调优手段。

如果 etcd 的 Leader 服务大量并发客户端，这就会导致 follower 的请求的处理被延迟因为网络延迟。follower 的 send buffer 中能看到错误的列表，如下所示：

dropped MsgProp to 247ae21ff9436b2d since streamMsg‘s sending buffer is full

dropped MsgAppResp to 247ae21ff9436b2d since streamMsg‘s sending buffer is full

 

这些错误可以通过提高 Leader 的网络优先级来提高 follower 的请求的响应。可以通过流量控制机制来提高:

// 针对 2379、2380 端口放行
$ tc qdisc add dev eth0 root handle 1: prio bands 3
$ tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip sport 2380 0xffff flowid 1:1
$ tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport 2380 0xffff flowid 1:1
$ tc filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip sport 2379 0xffff flowid 1:1
$ tc filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip dport 2379 0xffff flowid 1:1

// 查看现有的队列

$ tc -s qdisc ls dev enp0s8
qdisc prio 1: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 258578 bytes 923 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

// 删除队列

$ tc qdisc del dev enp0s8 root 

数据规模

etcd 的硬盘存储上限（默认是 2GB）, 当 etcd 数据量超过默认 quota 值后便不再接受写请求，可以通过设置 --quota-backend-bytes 参数来增加存储大小,quota-backend-bytes 默认值为 0，即使用默认 quota 为 2GB，上限值为 8 GB，具体说明可参考官方文档：https://github.com/etcd-io/etcd/blob/master/Documentation/dev-guide/limit.md 。

The default storage size limit is 2GB, configurable with `--quota-backend-bytes` flag. 8GB is a suggested maximum size for normal environments and etcd warns at startup if the configured value exceeds it.

以下摘自 当 K8s 集群达到万级规模，阿里巴巴如何解决系统各组件性能问题？

阿里进行了深入研究了 etcd 内部的实现原理，并发现了影响 etcd 扩展性的一个关键问题在底层 bbolt db 的 page 页面分配算法上：随着 etcd 中存储的数据量的增长，bbolt db 中线性查找 “连续长度为 n 的 page 存储页面” 的性能显著下降。 为了解决该问题，我们设计了基于 segregrated hashmap 的空闲页面管理算法，hashmap 以连续 page 大小为 key, 连续页面起始 page id 为 value。通过查这个 segregrated hashmap 实现 O(1) 的空闲 page 查找，极大地提高了性能。在释放块时，新算法尝试和地址相邻的 page 合并，并更新 segregrated hashmap。更详细的算法分析可以见已发表在 CNCF 博客的博文。 通过这个算法改进，我们可以将 etcd 的存储空间从推荐的 2GB 扩展到 100GB，极大地提高了 etcd 存储数据的规模，并且读写无显著延迟增长。 pull request ：https://github.com/etcd-io/bbolt/pull/141

目前社区已发布的 v3.4 系列版本并没有说明支持数据规模可达 100 G。

2.

etcd 性能测试

测试环境：本机 mac 使用 virtualbox 安装 vm，所有 etcd 实例都是运行在在 vm 中的 docker 上

参考官方文档：https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/performance.md

安装 etcd 压测工具 benchmark：

1. // 下载benchmarck包
$ go get go.etcd.io/etcd/tools/benchmark

2. // 将benchmarck二进制文件放在gopath目录下

3. // 验证是否安装成功
$ benchmark  // 会显示help信息

本文仅对 etcd v3.3.10 以及 v3.4.1 进行压测。

写入测试

# write to leader
benchmark --endpoints=${HOST_1} --target-leader --conns=1 --clients=1     put --key-size=8 --sequential-keys --total=10000 --val-size=256
benchmark --endpoints=${HOST_1} --target-leader  --conns=100 --clients=1000     put --key-size=8 --sequential-keys --total=100000 --val-size=256

# write to all members
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000     put --key-size=8 --sequential-keys --total=100000 --val-size=256