Performance whitepaper

Testing tools

This topic describes how to test Cloud Cassandra and provides some of our benchmark test results. Because we continue to optimize the kernel and cloud environment, these benchmark results may not represent optimal performance and will be updated periodically. To estimate the required size for your Cassandra instance, run some basic tests using the methods described in this topic. However, the best approach is to simulate your actual business workload on the instance. This method is more accurate than any external testing tool.

Testing tool

We use the industry-standard testing tool, Yahoo! Cloud Serving Benchmark (YCSB) 0.15.0, which is the latest release version. For more information, see https://github.com/brianfrankcooper/YCSB/tree/0.15.0/cassandra.

Staging environment

The tests were performed on a purchased Cloud Cassandra instance.

Network: VPC Network. The client and server are in the same region and zone. Instance scale: One data center (DC) with three nodes. Instance capacity: 400 GB standard SSD per node. Note that capacity can affect performance. Stress testing client: ecs.c6.2xlarge (8-core, 16 GB). Instance types: All instance types currently supported by Cloud Cassandra.

Test workload details

Throughput and latency vary because business workloads differ in factors such as the number of fields per row and the amount of data per row. This topic uses the default YCSB workloada for testing. Adjust the YCSB parameters to best match your business workload. Most Cassandra-related test parameters also use default values. For more information, see the YCSB documentation.

Key parameters

• 10 fields per row (default)

• 1 KB per row (default)

• Read/write ratio: 95:5

• Read/write consistency level: ONE (default)

• Two replicas. We use two replicas because the instances use cloud disks.

• Stress testing threads: Dynamically adjusted based on the instance type. For details, see the test results.

• Data volume (recordcount): The number of rows to import. This is dynamically adjusted based on the instance type. For details, see the test results.

• Number of operations (operationcount): The number of operations is the same as the data volume.

Note that adjusting the consistency level affects performance. Adjust it as needed for your business.

Test steps

1. Create a test table

# Replace cn-shanghai-g with the data center ID (DC Name) of your instance. You can find this in the console.
create keyspace ycsb WITH replication = {'class': 'NetworkTopologyStrategy', 'cn-shanghai-g': 2};
create table ycsb.usertable (y_id varchar primary key, field0 varchar, field1 varchar, field2 varchar, field3 varchar, field4 varchar, field5 varchar, field6 varchar, field7 varchar, field8 varchar, field9 varchar);
                        

2. Install the testing tool

wget https://github.com/brianfrankcooper/YCSB/releases/download/0.15.0/ycsb-cassandra-binding-0.15.0.tar.gz
tar -zxf ycsb-cassandra-binding-0.15.0.tar.gz
                        

3. Edit workloads/workloada

Add the following three lines.

hosts=cds-xxxxxxxx-core-003.cassandra.rds.aliyuncs.com # The database connection endpoint. You can find this in the console.
cassandra.username=cassandra # This account must have permissions to read from and write to the ycsb keyspace.
cassandra.password=123456 # If you forget the password, you can change it in the console.
                        

4. Data preparation (write-only test)

nohup ./bin/ycsb load cassandra2-cql -threads $THREAD_COUNT -P workloads/workloada -s > $LOG_FILE 2>&1 &
                        

The results of this test show the maximum write throughput. To test for maximum throughput, gradually increase `$THREAD_COUNT` and check if throughput increases. Also, ensure the stress testing client has sufficient specifications.

5. Stress testing (read/write mix test)

nohup ./bin/ycsb run cassandra2-cql -threads $THREAD_COUNT -P workloads/workloada -s > $LOG_FILE 2>&1 &
                        

The results of this test show the performance for a mixed read/write workload.

Test results

The test results are for reference only. Latency and throughput vary with different workloads. Use the methods described above with different parameters, stress levels, and larger data volumes for longer durations to obtain results that better reflect your business scenario. Note that the client specifications also affect the test results. Do not use burstable instance types.

Explanation of test results

• Load: The data preparation phase (write-only test).

• Run: The stress testing phase (mixed read/write test).

• OPS: Operations per second. This represents the throughput for the entire phase.

• WAVG: Average write latency in microseconds.

• RAVG: Average read latency in microseconds.

• RP999: 99.9th percentile read latency in microseconds.

• Threads: 100/100. This indicates the number of YCSB threads for the data preparation phase and the stress testing phase, respectively.

The stress testing phase is divided into two groups: one for full load and one for normal load.

80% CPU load

60% CPU load