Couchbase Pillowfight工具--num-threads参数机制及验证方法

可以通过Couchbase CLI工具和Web UI来验证--num-threads的运行逻辑，以及线程的文档访问范围，以下是具体操作方案：

一、CLI工具验证 #

1. 查看详细线程日志 #

修改你的测试命令，添加-vv参数输出线程级别的操作细节，并将日志写入文件：

/opt/couchbase/bin/cbc-pillowfight -U couchbase://xx.xx.xx.xx/data1 -u <你的用户名> -P <你的密码> --min-size 1000 --max-size 1000 --json --set-pct 0 --batch-size 1 --num-items 24000000 --num-threads 20 --rate-limit 8000 --key-prefix a --no-population -vv > pillowfight.log 2>&1

打开日志文件，搜索Thread关键字，会看到类似以下内容：

Thread 0: Performing GET on key 'a:45678'
Thread 1: Performing GET on key 'a:1204567'
Thread 2: Performing GET on key 'a:2401234'

对比不同线程处理的key，会发现它们的数值范围无重叠——这说明20个线程各自负责独立的key子集（总num-items会被平均分配给所有线程，即每个线程处理1200000个key），不会重复访问同一文档。

2. 实时监控Bucket操作统计 #

在测试运行期间，新开终端执行以下命令查看bucket的GET操作计数：

/opt/couchbase/bin/cbc-stats -U couchbase://xx.xx.xx.xx/data1 -u <你的用户名> -P <你的密码> get

观察get_ops字段的数值增长速率，正常情况下会接近你设置的--rate-limit 8000，这直接反映20个线程在并发发送请求。

二、Web UI验证 #

1. 监控Bucket级别的请求吞吐量 #

1. 登录Couchbase UI，进入Buckets > data1 > Metrics标签页
2. 查看Operations面板下的Get Ops指标：测试期间该指标会稳定在接近8000的数值（集群性能足够的前提下），这是20线程并发请求的直观表现。

2. 查看节点级别的请求分布 #

1. 进入Servers页面，点击任意节点的Metrics标签页
2. 查看Get Ops指标：会看到请求被分散到集群的各个节点，符合多线程独立发送请求、key按哈希分布到不同节点的逻辑。

3. 验证key访问范围（可选） #

若集群开启了key级别的统计功能，可通过Bucket Explorer搜索前缀a:的key，或用CBQ执行查询查看key的访问次数：

SELECT meta().id, couchbase_stats().access_count FROM data1 WHERE meta().id LIKE 'a:%' LIMIT 5;

通过对比不同key的访问次数，能确认线程是否在访问独立的key子集。

关于--num-threads的工作逻辑 #

--num-threads参数会让cbc-pillowfight创建多个独立的客户端实例，每个线程负责一个专属的key范围：总num-items会被平均分配给所有线程，因此20个线程各自处理1200000个不同的key，不会出现多线程访问同一文档的情况（除非num-items小于线程数，此场景下才会有重叠）。

内容的提问来源于stack exchange，提问作者Debasis Mallick