Load testing applies traffic to a database to find how much it can handle before throughput stops improving or latency becomes too slow. For a ScyllaDB cluster, it supports capacity planning: compare the measured traffic limit with expected demand, then size the cluster before users encounter the limit. It also gives monitoring dashboards real reads, writes, and latency to display. section 11.0 section 11.2 section 11.3.3
A useful test resembles the workload the application will actually create. cassandra-stress can use its generic schema for an approximate infrastructure benchmark, but a user-supplied schema and queries produce a more accurate result. Run it against one table at a time; testing multiple tables requires concurrent runs or a more sophisticated tool. section 11.2 section 11.2.1
Set up a representative cassandra-stress test by:
- Use a separate keyspace so generated test data does not pollute the existing application data. section 11.2.1
- Choose the keyspace and table, then describe each column’s generated values in YAML. section 11.2.1
- Tune value size, population, and clustering values so row sizes, distinct values, and values per partition resemble expected data. section 11.2.1
- Define the read query and set a read/write ratio that reflects demand; the article-summary example uses 1,000 reads per write. section 11.2.1 section 11.2.2
- Run the test while it increases worker threads and traffic, then inspect each run’s throughput, latency percentiles, errors, and dashboard effects. section 11.2.2
keyspace: stress
table: article_summaries_by_date
columnspec:
- name: date_bucket
population: uniform(0..240)
- name: id
cluster: uniform(10..25)
- name: author_name
size: uniform(5..20)
- name: score
population: uniform(1..100)
- name: title
size: uniform(20..50)
queries:
read:
cql: SELECT * FROM article_summaries_by_date WHERE date_bucket = ?
fields: samerow
This YAML profile ties a stress keyspace and article-summary table to representative column distributions and a partition-key read query. It is the bridge between a generic benchmark and an application-shaped workload. section 11.2.1
Reading a ramp-up result
A read-heavy test initially reaches nearly 5,000 partitions per second with a 99.9th-percentile latency of 4.5 ms. A later run reaches about 25,000 partitions per second, but 99.9th-percentile latency rises to about 45 ms. More throughput is therefore not automatically a better operating point: evaluate it against an acceptable latency target and expected traffic. section 11.2.2 section 11.4
Load tests help reveal whether demand is concentrated or overwhelming the cluster, but they do not replace observation. Use dashboards to correlate growing traffic and latency; tracing and partition-key visibility can help diagnose hotspots when latency rises. If desired traffic exceeds cluster capacity, reducing demand is a short-term response and expanding the cluster may be necessary. section 11.2.2 section 11.4 section 11.1.5
