A Practical Guide to Benchmarking, Concurrency Testing, and Performance Validation

Load testing is essential when tuning a MariaDB + MaxScale environment. It validates your sizing assumptions, exposes bottlenecks, and helps measure the real impact of features like multiplexing, connection pooling, and caching.

In this guide, we walk through:

1. Installing Sysbench
2. Creating a test database and user
3. Preparing datasets
4. Running moderate and high-concurrency tests
5. Understanding key performance metrics
6. Cleaning up after tests

All examples benchmark MariaDB through MaxScale, which gives you realistic proxy-layer performance data.

Please note that when you are following the instructions, make sure that the mysql_host is set to your maxscale IP address.

Installing Sysbench

Sysbench is not always available in default repositories, or often ships with an outdated version. Below are installation steps for the most common Linux distributions.

Install on Rocky Linux / RHEL / CentOS

Option 1: Install from distro repositories

sudo dnf install -y epel-release
sudo dnf install -y sysbench

sudo dnf install -y epel-release
sudo dnf install -y sysbench

Option 2: Install the latest Sysbench from packagecloud

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash 
sudo dnf install -y sysbench

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash 
sudo dnf install -y sysbench

Install on Debian / Ubuntu

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
sudo apt update
sudo apt install -y sysbench

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
sudo apt update
sudo apt install -y sysbench

Test Environment Assumptions

All examples assume:

• You are testing through MaxScale, not directly to MariaDB
• Default port: 3306
• MaxScale has routing and credentials configured
• Sysbench >= 1.0 (modern LUA-based OLTP tests)

Load Testing with Sysbench

Load testing validates the sizing assumptions and helps tune configuration for real conditions.

Below are fully working sysbench steps, including user creation, dataset preparation, benchmark execution, and cleanup.

Step 1: Create Test Database and User on your database

CREATE DATABASE sbtest;
CREATE USER 'sbuser'@'%' IDENTIFIED BY 'aBcd123_';
GRANT ALL PRIVILEGES ON sbtest.* TO 'sbuser'@'%';

CREATE DATABASE sbtest;
CREATE USER 'sbuser'@'%' IDENTIFIED BY 'aBcd123_';
GRANT ALL PRIVILEGES ON sbtest.* TO 'sbuser'@'%';

Step 2: Prepare the Dataset

Example: 10 tables × 10,000 rows each.

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=10 \
--table-size=10000 \
prepare

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=10 \
--table-size=10000 \
prepare

Step 3: Run the Load Test

A moderate concurrency test helps establish a baseline before you begin applying tuning (multiplexing, caching, thread adjustments, etc.).

Moderate Concurrency (32 threads)

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=10 \
--table-size=10000 \
--threads=32 \
--time=300 \
--report-interval=5 \
run

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=10 \
--table-size=10000 \
--threads=32 \
--time=300 \
--report-interval=5 \
run

Key Metrics to Monitor

Sysbench reports several important metrics:

• TPS / QPS – transactions and queries per second
• Avg latency – overall request latency
• 95th / 99th percentile latency – critical for user experience under load
• Errors / retries – signs of overload
• MaxScale worker thread CPU usage
• Backend CPU and I/O load in MariaDB

These provide a clear view of how MaxScale and the database perform under moderate load.

An example output is:

SQL statistics:
    queries performed:
        read:         344890
        write:         98095
        other:         49124
        total:        492109
    transactions:      24489 (81.62 per sec.)
    queries:          492109 (1640.26 per sec.)
    ignored errors:      146 (0.49 per sec.)
    reconnects:            0 (0.00 per sec.)

General statistics:
    total time:             300.0174s
    total number of events: 24489

Latency (ms):
    min: 14.07
    avg: 24.50
    max: 65.27
    95th percentile: 33.72
    sum: 599920.89

Threads fairness:
    events (avg/stddev):         12244.5000/146.50
    execution time (avg/stddev): 299.9604/0.00

SQL statistics:
    queries performed:
        read:         344890
        write:         98095
        other:         49124
        total:        492109
    transactions:      24489 (81.62 per sec.)
    queries:          492109 (1640.26 per sec.)
    ignored errors:      146 (0.49 per sec.)
    reconnects:            0 (0.00 per sec.)

General statistics:
    total time:             300.0174s
    total number of events: 24489

Latency (ms):
    min: 14.07
    avg: 24.50
    max: 65.27
    95th percentile: 33.72
    sum: 599920.89

Threads fairness:
    events (avg/stddev):         12244.5000/146.50
    execution time (avg/stddev): 299.9604/0.00

Step 4: Clean-up After Test

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=10 \
cleanup

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=10 \
cleanup

Optionally remove the user and schema:

DROP DATABASE sbtest;
DROP USER 'sbuser'@'%';

DROP DATABASE sbtest;
DROP USER 'sbuser'@'%';

High-Concurrency Testing (Peak Load)

This test helps validate:

• Worker thread saturation
• Backend connection pool limits
• MaxScale routing behaviour under pressure
• Replication lag (for RW split setups)
• Whether increasing MaxScale threads improves performance

Step 1: Prepare Larger Dataset

20 tables × 200,000 rows:

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=20 \
--table-size=200000 \
prepare

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=20 \
--table-size=200000 \
prepare

Step 2: Run High-Concurrency Benchmark (128 threads)

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=20 \
--table-size=200000 \
--threads=128 \
--time=600 \
--report-interval=5 \
run

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=20 \
--table-size=200000 \
--threads=128 \
--time=600 \
--report-interval=5 \
run

Step 3: Cleanup

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=20 \
cleanup

sysbench /usr/share/sysbench/oltp_read_write.lua \
--db-driver=mysql \
--mysql-host= \
--mysql-port=3306 \
--mysql-user=sbuser \
--mysql-password=aBcd123_ \
--mysql-db=sbtest \
--tables=20 \
cleanup

Interpreting Results

You should compare:

Before vs. After tuning MaxScale:

• Multiplexing enabled vs disabled
• Caching on/off
• MaxScale thread count adjustments
• Backend connection pool size
• Different Sysbench workloads (read-only vs read/write)

What to look for

• Rising latency → saturation or queue buildup
• TPS that doesn’t scale → CPU or I/O bottleneck
• Increased replication lag in R/W split setups
• CPU imbalance across MaxScale worker threads
• Backend connections approaching
  persistpoolmax * maxscale_thread_count

Documenting these results helps you build accurate performance baselines.

Additional Recommendations

• Run each test multiple times to remove noise
• Capture system metrics using:
  • sar, iostat, vmstat
  • Prometheus + Grafana
• Test multiple thread levels:
  • 1, 8, 16, 32, 64, 128, 256

Summary

This expanded guide provides everything you need to:

• Install Sysbench on major Linux distributions
• Create a repeatable and realistic benchmarking environment
• Run moderate and high-concurrency workloads through MaxScale
• Measure proxy overhead, latency behaviour, and saturation points
• Tune MaxScale and MariaDB for real-world traffic patterns

Load testing is the most reliable way to validate architecture decisions, and Sysbench remains one of the best tools for exposing performance bottlenecks quickly.