AHBench is a benchmark test suite developed by the ApsaraDB for Lindorm (Lindorm) team. You can use AHBench to test the performance of a Lindorm cluster or an HBase cluster in a few clicks.
AHBench is integrated with Yahoo! Cloud Serving Benchmark (YCSB). You can use AHBench to check whether you can collect data, manage processes, and aggregate results in a Lindorm cluster. You can use AHBench to test the features that are described in the performance white paper of Lindorm. The configuration of AHBench is simple. You can use this tool suite to perform benchmark tests in a few clicks.
Download AHBench from the download link. Upload the downloaded file to your client node and decompress the file. The client node is used for stress testing.
Configure a runtime environment
The client node must meet the following requirements:
- Linux operating system
- JDK 1.8 +
- python 2.7
- We recommend that you use a client node that has at least 16 exclusive CPU cores.
Configure a cluster endpoint (required)
Configure the endpoint of a Lindorm cluster or an HBase cluster in the AHBench/conf/hbase-site.xml file.
Configure environment variables for AHBench (required)
Open the AHBench/conf/ahbench-env.properties file and configure environment variables for AHBench.
vi AHBench/conf/ahbench-env.properties # Configure the installation path for the Java Development Kit (JDK). If the JDK is installed in the system path, skip this step. # JAVA_HOME=/usr/java/jdk1.8.0/ # Configure the version of the HBase cluster. If you use HBase 1.x, set HBASE_VERSION to 1. If you use HBase 2.x, set HBASE_VERSION to 2. HBASE_VERSION=2
Configure parameters for testing (optional)
# Configure the compression algorithm for the test table. # Valid values of the compression parameter: NONE, LZO, SNAPPY, GZ, LZ4, and ZSTD. # Take note of this point: Some test systems may support only part of the compression algorithms. # We recommend that you use the Zstandard compression algorithm for a Lindorm cluster. ahbench.table.compression=SNAPPY # Configure the encoding algorithm for the table. The following encoding algorithms are supported: # NONE DIFF INDEX # Take note of this point: Some test systems may support only part of the encoding algorithms. # We recommend that you use the INDEX encoding algorithm for a Lindorm cluster. ahbench.table.encoding=DIFF
Start a test
- Quick test
The test data includes 10 million entries, which occupies at least 20 GB memory. The test takes about 40 minutes and the required time may vary based on different system editions.
cd AHBench ./fast_test
- Full test
The test data includes 2 billion entries, which occupies at least 2 TB memory. The test takes about 25 hours and the required time may vary based on different system editions.
cd AHBench ./full_test
You do not need to import data again if you want to repeat a test. This saves the time. If you skip the data import step, the test takes about 3.5 hours. The required time may vary based on different system editions.
cd AHBench ./full_test --skipload
Analyze test results
After all tests are performed, a comma-separated values (CSV) file is generated in the directory. You can import the test results to the data analysis software such as Excel or Numbers for further comparative analysis.
You can view the following sample CSV file:
- The test suite uses the ahbenchtest-read and ahbenchtest-write tables for testing. You may delete and create the tables during the test. Therefore, you must have permissions to delete the tables.
- We recommend that you do not use the test suite in a production environment. The system may stop responding due to the heavy workload during the test.
- If AHBench returns an error and unexpectedly quits, check the following items:
- Check whether JAVA_HOME is properly configured and the Python runtime environment is installed.
- Check whether the endpoint of the cluster is valid.
- Check whether the version of the HBase cluster is valid.
- Check whether the cluster supports the specified compression algorithm.
- Check whether the cluster is properly running.
- Check whether the storage of the cluster is sufficient.
- The cluster runs on an Elastic Compute Service (ECS) instance that provides a virtual runtime environment. The performance of clusters that have the same specifications may fluctuate. The normal range of fluctuation is between 5% and 10%.