TiProxy パフォーマンステストレポート

このレポートでは、Sysbench の OLTP シナリオで TiProxy のパフォーマンスをテストし、 HAプロキシと比較します。

結果は次のとおりです。

• TiProxy の QPS 上限はワークロードの種類によって影響を受けます。クライアントの同時実行数が同じで、TiProxy の CPU 使用率が 80% 未満の場合、QPS は HAProxy より 5% 未満低くなります。このような場合、クライアントの同時実行数を増やすことで QPS を改善できる場合が多くあります。同じ QPS の場合、TiProxy の CPU 使用率は HAProxy より約 25% 高くなります。そのため、より多くの CPU リソースを確保する必要があります。
• TiProxyが保持できるTiDBサーバーインスタンスの数は、ワークロードの種類によって異なります。Sysbenchの基本ワークロードでは、TiProxyは同じモデルのTiDBサーバーインスタンスを5～12個保持できます。
• クエリ結果セットの行数は TiProxy の QPS に大きな影響を与え、その影響は HAProxy の場合と同じです。
• TiProxy のパフォーマンスは、vCPU の数にほぼ比例して向上します。そのため、vCPU の数を増やすことで、QPS の上限を効果的に向上させることができます。
• 長い接続の数と短い接続を作成する頻度は、TiProxy の QPS にほとんど影響を与えません。
• TiProxyのCPU使用率が高いほど、 トラフィックキャプチャ有効化した場合のQPSへの影響が大きくなります。TiProxyのCPU使用率が約70%の場合、トラフィックキャプチャを有効化すると、平均QPSが約3%、最小QPSが約7%低下します。後者の低下は、トラフィックファイルの圧縮中に発生する周期的なQPS低下によって発生します。

テスト環境

ハードウェア構成

ソフトウェア

コンフィグレーション

TiProxy の設定

テストでは、クライアントと TiProxy 間、または TiProxy と TiDBサーバー間で TLS が有効になっていません。

proxy.conn-buffer-size: 131072

HAProxy 設定 - haproxy.cfgファイル

global                                      # Global configuration.
    log         127.0.0.1 local2            # Specifies the global syslog server. You can define up to two.
    pidfile     /var/run/haproxy.pid        # Write the PID of the HAProxy process to pidfile.
    maxconn     4096                        # The maximum number of concurrent connections that a single HAProxy process can accept, equivalent to the command line parameter "-n".
    nbthread    4                           # The maximum number of threads. The upper limit of the number of threads is the same as the number of CPUs.
    user        haproxy                     # Same as UID parameter.
    group       haproxy                     # Same as GID parameter. A dedicated user group is recommended.
    daemon                                  # Run HAProxy as a daemon in the background, which is equivalent to the command line parameter "-D". You can also disable it with the "-db" parameter on the command line.
    stats socket /var/lib/haproxy/stats     # The location where the statistics are saved.

defaults                                    # Default configuration.
    log global                              # Inherit the settings of the global configuration section.
    retries 2                               # The maximum number of times to try to connect to the upstream server. If the number of retries exceeds this value, the backend server is considered unavailable.
    timeout connect  2s                     # The timeout period for HAProxy to connect to the backend server. If the server is located on the same LAN as HAProxy, set it to a shorter time.
    timeout client 30000s                   # The timeout period for the client to be inactive after the data transmission is completed.
    timeout server 30000s                   # The timeout period for the server to be inactive.

listen tidb-cluster                         # Configure database load balancing.
    bind 0.0.0.0:3390                       # Floating IP address and listening port.
    mode tcp                                # HAProxy uses layer 4, the transport layer.
    balance leastconn                      # The server with the least number of connections receives the connection first. `leastconn` is recommended for long session services, such as LDAP, SQL, and TSE, rather than short session protocols, such as HTTP. This algorithm is dynamic, and the server weight is adjusted during operation for slow-start servers.
    server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3      # Detects port 4000 at a frequency of once every 2000 milliseconds. If it is detected as successful twice, the server is considered available; if it is detected as failed three times, the server is considered unavailable.
    server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3
    server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3

基本的な作業負荷テスト

テスト計画

このテストは、ポイントセレクト、読み取り専用、書き込み専用、読み取り書き込みの4種類のワークロードにおけるTiProxyとHAProxyのQPSを比較することを目的としています。各ワークロードは異なる同時実行性でテストされ、TiProxyとHAProxyのQPSを比較します。

テストを実行するには、次のコマンドを使用します。

sysbench $testname \
    --threads=$threads \
    --time=1200 \
    --report-interval=10 \
    --rand-type=uniform \
    --db-driver=mysql \
    --mysql-db=sbtest \
    --mysql-host=$host \
    --mysql-port=$port \
    run --tables=32 --table-size=1000000

ポイント選択

TiProxy テスト結果:

HAProxy テスト結果:

読み取り専用

TiProxy テスト結果:

HAProxy テスト結果:

書き込み専用

TiProxy テスト結果:

HAProxy テスト結果:

読み書き

TiProxy テスト結果:

HAProxy テスト結果:

結果セットテスト

テスト計画

このテストは、異なる結果セット行数におけるTiProxyとHAProxyのパフォーマンスを比較することを目的としています。このテストでは、同時実行数を100に設定し、結果セット行数を10、100、1000、10000とした場合のTiProxyとHAProxyのQPSを比較します。

テストを実行するには、次のコマンドを使用します。

sysbench oltp_read_only \
    --threads=100 \
    --time=1200 \
    --report-interval=10 \
    --rand-type=uniform \
    --db-driver=mysql \
    --mysql-db=sbtest \
    --mysql-host=$host \
    --mysql-port=$port \
    --skip_trx=true \
    --point_selects=0 \
    --sum_ranges=0 \
    --order_ranges=0 \
    --distinct_ranges=0 \
    --simple_ranges=1 \
    --range_size=$range_size
    run --tables=32 --table-size=1000000

テスト結果

TiProxy テスト結果:

HAProxy テスト結果:

スケーラビリティテスト

テスト計画

このテストは、TiProxy のパフォーマンスがスペックに比例しているかどうかを検証し、TiProxy のスペックをアップグレードすることで QPS の上限を向上できるかどうかを確認することを目的としています。このテストでは、vCPU 数と同時実行数が異なる TiProxy インスタンスを使用して QPS を比較します。

テストを実行するには、次のコマンドを使用します。

sysbench oltp_point_select \
    --threads=$threads \
    --time=1200 \
    --report-interval=10 \
    --rand-type=uniform \
    --db-driver=mysql \
    --mysql-db=sbtest \
    --mysql-host=$host \
    --mysql-port=$port \
    run --tables=32 --table-size=1000000

テスト結果

長時間接続テスト

テスト計画

このテストは、クライアントが長時間接続を使用する場合、多数のアイドル接続がQPSに最小限の影響しか与えないことを検証することを目的としています。このテストでは、5,000、10,000、15,000のアイドル状態の長時間接続を作成し、 sysbench実行します。

このテストでは、 conn-buffer-size構成のデフォルト値を使用します。

proxy.conn-buffer-size: 32768

テストを実行するには、次のコマンドを使用します。

sysbench oltp_point_select \
    --threads=50 \
    --time=1200 \
    --report-interval=10 \
    --rand-type=uniform \
    --db-driver=mysql \
    --mysql-db=sbtest \
    --mysql-host=$host \
    --mysql-port=$port \
    run --tables=32 --table-size=1000000

テスト結果

短時間接続テスト

テスト計画

このテストは、クライアントが短い接続を使用する場合、頻繁な接続の作成と破棄がQPSに最小限の影響しか与えないことを検証することを目的としています。このテストでは、別のクライアントプログラムを起動し、 sysbench実行しながら、1秒あたり100、200、300の短い接続を作成および切断します。

テストを実行するには、次のコマンドを使用します。

sysbench oltp_point_select \
    --threads=50 \
    --time=1200 \
    --report-interval=10 \
    --rand-type=uniform \
    --db-driver=mysql \
    --mysql-db=sbtest \
    --mysql-host=$host \
    --mysql-port=$port \
    run --tables=32 --table-size=1000000

テスト結果

トラフィックキャプチャテスト

テスト計画

このテストは、TiProxyにおけるトラフィックキャプチャパフォーマンスへの影響を評価することを目的としています。TiProxy v1.3.0を使用し、トラフィックキャプチャを有効または無効にした場合のQPSとTiProxyのCPU使用率を比較した後、異なる同時実行数でsysbench実行します。トラフィックファイルの圧縮によって周期的にQPSが変動するため、このテストでは平均QPSと最小QPSの両方を比較します。

テストを実行するには、次のコマンドを使用します。

sysbench oltp_read_write \
    --threads=$threads \
    --time=1200 \
    --report-interval=5 \
    --rand-type=uniform \
    --db-driver=mysql \
    --mysql-db=sbtest \
    --mysql-host=$host \
    --mysql-port=$port \
    run --tables=32 --table-size=1000000

テスト結果