This topic describes how to perform benchmark tests for ApsaraDB for Cassandra and provides sample results. The test results may vary as the kernel and cloud environments are constantly optimized. If you need to estimate the ApsaraDB for Cassandra instance scales suitable for your business, you can refer to the test approaches described in this topic. To obtain a precise result, we recommend that you run simulated services on instances.

Test tool

Yahoo! Cloud Serving Benchmark (YCSB) 0.15.0 (new released). For more information, visit https://github.com/brianfrankcooper/YCSB/tree/0.15.0/cassandra.

Test environment

Buy an ApsaraDB for Cassandra instance of the following specifications:

Network: VPC. Deploy the client and server in the same region and zone. Instance architecture: a data center that contains three nodes. Instance storage: 400 GB per node and standard SSD. Stress testing server type: ecs.c6.2xlarge (8 vCPUs, 16 GB). Instance specifications: all specifications supported by ApsaraDB for Cassandra.

Test loads

Different services bear different loads such as the number of fields and data volume in each row and result in different throughput and latency. This topic uses the default workloada provided by YCSB for testing. You can customize YCSB parameters based on your service. Most ApsaraDB for Cassandra parameters use the default values. For more information, visit https://github.com/brianfrankcooper/YCSB/tree/0.15.0/cassandra.

Parameters

  • 10 fields per row (default).
  • 1 KB records per row (default).
  • Read/write operation ratio: 95:5.
  • Read/write consistency level: ONE (default).
  • Number of replicas: Configure two replicas because the standard SSD is used.
  • Stress testing threads: modified based on the instance specifications. For more information, see the test results.
  • recordcount: the row number of imported data. It is modified based on the specifications. For more information, see the test results.
  • operationcount: the number of stress testing operations. It is the same as recordcount.https://github.com/brianfrankcooper/YCSB/tree/0.15.0/cassandra

Note that adjusting the consistency level will affect the performance. Specify a consistency level based on your business requirements.

Test procedure

1. Create a test table

# Replace cn-shanghai-g with the data center ID of the tested instance. You can view the Data Center Name parameter in the ApsaraDB for Cassandra 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 test 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 the workloads/workloada code

Add the following lines of code to workloada:

hosts=cds-xxxxxxxx-core-003.cassandra.rds.aliyuncs.com #The endpoint of the instance. You can view it in the ApsaraDB for Cassandra console.
cassandra.username=cassandra #The account of the instance. The account must have permissions to read and write ycsb keyspace.
cassandra.password=123456 #The password of the account. You can change the password in the console.

4. Prepare data (read performance test)

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

You can view the maximum throughput based on the test result. To test the maximum throughput, you must increase the value of $THREAD_COUNT and view whether the throughput increases. We recommend that you select medium or large specifications for the stress testing server.

5. Perform stress testing (read and write performance test)

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

You can view the read and write performance based on the test result.

Test results

The test results are for reference only. Different loads will result in different throughput and latency You can use various parameters, loads, data volumes, and time periods to obtain test results that suit your business. The client specifications will affect the performance. Do not use shared instances.

Result description

Load: the data preparation phase (read performance test). Run: the stress testing phase (read and write performance test). OPS: the operations per second, indicating the throughput in all phases. WAVG: the average write latency. Unit: microseconds. RAVG: the average read latency. Unit: microseconds. RP999: the 99.9% read latency. Unit: microseconds. Thread: the number of YCSB testing threads during data preparation/the number of YCSB testing threads during stress testing. For example, 100/100.

A full load test and a normal load test are performed during the stress testing phase.

80% CPU load

Specification Thread Data volume (ten thousand rows) Load OPS Load WAVG Run OPS Run WAVG Run RAVG Run RP95 Run RP99 Run RP999
4 cores, 8 GB 100/100 1,600 32,277 3,071 29,745 2,846 3,363 7,795 23,039 43,999

60% CPU load

Specification Thread Data volume (ten thousand rows) Load OPS Load WAVG Run OPS Run WAVG Run RAVG Run RP95 Run RP99 Run RP999
4 cores, 8 GB 100/16 1,600 32,063 3,093 16,721 514 974 1,879 3,047 28,063

Note: This topic lists only the test results of an instance based on standard SSD. The ultra disk provides high IOPS and brings little impact on performance when you test instances of the basic specifications by using a small amount of data. Therefore, instances based on ultra disks are not provided for reference. You can simulate loads based on your business during stress tests to obtain precise results. The impacts of applications must also be considered. For example, the garbage collection mechanism of Java clients causes latency.