CBC-PILLOWFIGHT(1)

CBC-PILLOWFIGHT(1) 💖

so bestie, welcome to the General Commands Manual page for cbc-pillowfight — yes that's the whole name, iconic, no notes. it lives in section 1 and it's about to be your new favorite chaos gremlin. let's get into it 🎀

---

✨ NAME ✨

cbc-pillowfight — Stress Test for Couchbase Client and Cluster 🥊🛏️

---

✨ SYNOPSIS ✨

cbc-pillowfight [OPTIONS]

that's it. that's the whole vibe. just options, go wild 💅

---

✨ DESCRIPTION ✨

okay so cbc-pillowfight spins up a specified number of threads, and each one just loops forever doing get and set operations against the cluster. it is, literally, a pillow fight in your database. except the pillows are network buffers. 🛏️

the stress test operates in the following order:

1. it will pre-load the items in the cluster (set by the --num-items option)
2. once the items are all loaded into the cluster, it will access all the items (within the --num-items specification), using a combination of storage and retrieval operations (the proportion of retrieval and storage operations are controlled via the --set-pct option)
3. operations are scheduled in batches. the batches represent a single pipeline (or network buffer) which is filled with a certain amount of operations (see the --batch-size option). these batch sizes are then sent over to the cluster and the requests are serviced by it.

Tuning

ngl, getting the right benchmark numbers highly depends on the type of environment the client is being run in. here's the tea on specific settings which may make pillowfight generate more operations 👇

• increasing the batch size will typically speed up operations, but increasing the batch size too much will actually slow it down. additionally, very high batch sizes will cause high memory usage. 😭
• adding additional threads will create additional client objects and connections, potentially increasing performance. adding too many threads will cause local and network resource congestion. 🫠
• decreasing the item sizes (the --min-size and --max-size options) will always yield higher performance in terms of operationd-per-second.
• limiting the working set (i.e. --num-items) will decrease the working set within the cluster, thereby increasing the chance that a given item will be inside the server's CPU cache (which is extremely fast), rather than in main memory (slower), or disk (much slower) 🐌

the benchmark tool sets up SIGQUIT (CTRL-/) handler and dumps useful diagnostics and metrics to STDERR on this signal. so if you hit CTRL-/ you get the receipts ✨

---

✨ OPTIONS ✨

options may be read either from the command line, or from a configuration file (see cbcrc(4)): 📄

the following options control workload generation:

• -B, --batch-size=BATCHSIZE — this controls how many commands are scheduled per cycles. want to simulate one operation at a time? set this value to 1. 🎯
• -I, --num-items=NUMITEMS — sets the total number of items the workload will access within the cluster. this also determines the working set size at the server and may affect disk latencies if set to a high number. ⚠️
• -p, --key-prefix=PREFIX — sets the prefix to prepend to all keys in the cluster. useful if you do not wish the items to conflict with existing data. no accidental collisions, we love to see it 💖
• --collection=scopeName.collectionName — access data based on full collection name path. multiple --collection filters can specify the different scopes with different collection names. note that default collection will not be used if the collection was specified — to enable default collection along with the named ones, it should be specified explicitly as --collection=_default._default. iykyk 🧚
• -t, --num-threads=NTHREADS — sets the number of threads (and thus the number of client instances) to run concurrently. each thread is assigned its own client object. very main character energy, every thread gets its own little life 👑
• -r, --set-pct=PERCENTAGE — the percentage of operations which should be mutations. a value of 100 means only mutations while a value of 0 means only retrievals. pick your fighter 🥊
• -n, --no-population — by default cbc-pillowfight will load all the items (see --num-items) into the cluster and then begin performing the normal workload. specifying this option bypasses this stage. useful if the items have already been loaded in a previous run. ✨
• --populate-only — stop after population. useful to populate buckets with large amounts of data. load it up and dip 🫶
• -m, --min-size=MINSIZE:
• -M, --max-size=MAXSIZE — specify the minimum and maximum value sizes to be stored into the cluster. this is typically a range, in which case each value generated will be between --min-size and --max-size bytes. 📏
• -E, --pause-at-end — when the workload completes, do not exit immediately, but wait for user input. this is helpful for analyzing open socket connections and state. it's giving "hold still, i'm looking at you" 👀
• -c, --num-cycles — specify the number of times the workload should cycle. during each cycle an amount of --batch-size operations are executed. setting this to -1 will cause the workload to run infinitely. 🔥
• --sequential — specify that the access pattern should be done in a sequential manner. this is useful for bulk-loading many documents in a single server. 🍓
• --start-at — this specifies the starting offset for the items. the items by default are generated with the key prefix (--key-prefix) up to the number of items (--num-items). the --start-at value will increase the lower limit of the items. this is useful to resume a previously cancelled load operation. the "un-pause" button, basically ⏯️
• -T, --timings — enabled timing recorded. timing histogram will be dumped to STDERR on SIGQUIT (CTRL-/). when specified a second time, it will dump a histogram of command timings and latencies to the screen every second. 📊
• -e, --expiry=SECONDS — set the expiration time on the document for SECONDS when performing each operation. note that setting this too low may cause not-found errors to appear on the screen. 😭

@@common-options.markdown@@

• d, --durability=LEVEL — specify durability level for mutation operations. known values are: "none", "majority", "majority_and_persist_to_active", "persist_to_majority". 💾
• p, --persist-to=NUMNODES — wait until the item has been persisted to at least NUMNODES nodes' disk. if NUMNODES is 1 then wait until only the master node has persisted the item for this key. you may not specify a number greater than the number of nodes actually in the cluster. -1 is a special value, which mean to use all available nodes. 🗄️
• r, --replicate-to=NREPLICAS — wait until the item has been replicated to at least NREPLICAS replica nodes. the bucket must be configured with at least one replica, and at least NREPLICAS replica nodes must be online. -1 is a special value, which mean to use all available replicas. 🪞
• --lock=TIME — this will retrieve and lock an item before update, making it inaccessible for modification until the update completed, or TIME has passed. 🔒
• --json — make pillowfight store document as JSON rather than binary. this will allow the documents to nominally be analyzed by other Couchbase services such as Query and MapReduce. 📝

JSON documents are created by creating an empty JSON object ({}) and then repeated populating it with Field_%d property names (where %d is 1 and higher), and setting its value to a repeating asterisk * up to 16 times:

{
    "Field_1": "****************",
    "Field_2": "****************",
    "Field_3": "****************",
    "Field_4": "****************",
    "Field_5": "********"
}

when using document size constraints, be aware that the minimum and maximum sizes (--min-size and --max-size) are not strict limits, and that the resultant sizes may be bigger or smaller by a few bytes in order to satisfy the requirements of proper JSON syntax. ⚠️

• --noop — use couchbase NOOP operations when running the workload. this mode ignores population, and all other document operations. useful as the most lightweight workload. 🪶
• --subdoc — use couchbase sub-document operations when running the workload. in this mode pillowfight will use Couchbase sub-document operations http://blog.couchbase.com/2016/february/subdoc-explained to perform gets and sets of data. this option must be used with --json. 🧬
• --pathcount — specify the number of paths a single sub-document operation should contain. by default, each subdoc operation operates on only a single path within the document. you can specify multiple paths to atomically executed multiple subdoc operations within a single command. 🌿

this option does not affect the --batch-size option as a subdoc command is considered as a single command (with respect to batching) regardless of how many operations it contains. 🎀

---

✨ ADDITIONAL OPTIONS ✨

the following options may be included in the connection string (via the -U option) as URI-style query params (e.g. couchbase://host/bucket?option1=value1&option2=value2) or as individual key=value pairs passed to the -D switch (e.g. -Doption1=value1 -Doption2=value). the -D will internally build the connection string, and is provided as a convenience for options to be easily passed on the command-line. 🔗

@@common-additional-options.markdown@@

---

(part 2 incoming, don't move 💖)

✨ EXAMPLES ✨

okay bestie this is the part where it all comes together, like the montage scene before the finale 💖

🔌 CONNECTION EXAMPLES 🔌

these ones show you how to hook cbc-pillowfight up to basically every kind of cluster setup you could possibly have. pick your fighter:

---

connect to a bucket (a_bucket) on a cluster on a remote host — this is for servers version 5.x and up. it uses account 'myname' and it'll ask you for the password interactively, no spoilers:

cbc-pillowfight -U couchbase://192.168.33.101/a_bucket -u myname -P-

run against a password-less bucket (a_bucket) on a cluster on a remote host — this one's for servers older than 5.x, so keep that in mind:

cbc-pillowfight -U couchbase://192.168.33.101/a_bucket

connect to an SSL cluster at secure.net where the cert is chillin locally at /home/couchbase/couchbase_cert.pem:

cbc-pillowfight -U couchbases://secure.net/topsecret_bucket?certpath=/home/couchbase/couchbase_cert.pem

connect to an SSL cluster at secure.net but ignore certificate verification — look, this is insecure, full stop, but it's handy for testing so we're not judging:

cbc-pillowfight -U couchbases://secure.net/topsecret_bucket?ssl=no_verify

connect to a password protected bucket (protected) on a remote host — for servers older than 5.x. it'll prompt you and the dots won't tell anyone how long your password is:

cbc-pillowfight -U couchbase://remote.host.net/protected -P -
Bucket password:
......

connect to a password protected bucket (again, servers older than 5.x) but put the password right on the command line — this is INSECURE but useful for testing dummy environments, and honestly we've all done it:

cbc-pillowfight -U couchbase://remote.host.net/protected -P t0ps3cr3t

connect to a bucket running on a cluster with a custom REST API port:

cbc-pillowfight -U http://localhost:9000/default

connect to a bucket running on a cluster with a custom memcached port:

cbc-pillowfight -U couchbase://localhost:12000/default

connect to a memcached (<http://memcached.org>) cluster using the binary protocol — important lore: a vanilla memcached cluster is not the same thing as a memcached bucket living inside a couchbase cluster (use the normal couchbase:// scheme for that one, bestie):

cbc-pillowfight -U memcached://host1,host2,host3,host4

connect to an SSL cluster at secure.net:

cbc-pillowfight -U couchbases://secure.net/topsecret_bucket

run against a bucket (a_bucket) on a cluster on a remote host:

cbc-pillowfight -U couchbase://192.168.33.101/a_bucket

run against a bucket (a_bucket) and use collections app.users and backup.stage — look at you, all fancy with multiple collections:

cbc-pillowfight --spec couchbase://127.0.0.1/a_bucket --username Administrator --password password \
                --collection app.users --collection backup.stage

---

📊 BENCHMARK EXAMPLES 📊

now for the part where you actually put it to work. these show you how to configure different types of workloads, so you can vibe-check your cluster properly 🔥

run with 20 threads/instances, each doing one operation at a time:

cbc-pillowfight -t 20 -B 1

run 100 iterations of 2MB item sizes, using a dataset of 50 items:

cbc-pillowfight -M $(1024*1024) -m $(1024*1024) -c 100 -I 50

use JSON documents of 100k each:

cbc-pillowfight --json -m 100000 -M 100000

stress-test sub-document mutations:

cbc-pillowfight --json --subdoc --set-pct 100

---

🌱 TODO 🌱

okay so here's the wishlist: instead of spawning threads for multiple instances, the goal is to offer a way to have multiple instances function cooperatively inside an event loop. one day, bestie, one day 🫶

---

💀 BUGS 💀

this command's options are subject to change. yes, for real. brace yourself, no cap.

---

👀 SEE ALSO 👀

• cbc(1)
• cbcrc(4)

go read those too, iykyk 💅

---

📜 HISTORY 📜

the cbc-pillowfight tool was first introduced in libcouchbase 2.0.7. a true icon, born in that era, still slaying 👑

---

okay that's literally the whole page, you made it to the end and i'm so proud of you 🌈💖 this whole thing is from CBC-PILLOWFIGHT(1), dated July 2024 — so like, reasonably recent, she's fresh. go forth and pillowfight responsibly, bestie 🦋🎀