📘
TiDBの負荷テスト
TiDBのローカル環境構築記事で作成した環境を使い、API経由で負荷テストを行います。
前提条件
TiDBローカル環境構築で行う
curlコマンドが使える
docker-composeでコンテナ作成済み
APIコンテナでDjangoが起動している
curlでの負荷テスト
まずは、curlで並列処理を行いGETとPOSTを行います。
GET
以下コマンドを実行します。
説明とすればこのコマンドはローカルAPIに対して1000回のHTTPリクエストをほぼ同時に実行し、その結果を捨てるような処理を行ってます。
seq 1 1000 | xargs -n1 -P1000 -I{} sh -c 'curl -sS http://127.0.0.1:8000/api/customers/ > /dev/null'
結果は以下になります。
1000回のGETのリクエスト結果になります。
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
[12/Aug/2025 08:25:57] "GET /api/customers/ HTTP/1.1" 200 97
・
・
・
メトリクスは以下になります。
ツールを使っての負荷テスト
各ツールを使っての負荷テストを行います。
ApacheBench
ApacheBenchは、HTTPサーバーやAPIの性能を測るための負荷試験ツールになります。
名前はApache由来だけど、Apache HTTP Server専用じゃなくて、HTTP/HTTPSなら何でも叩けます。
コマンド一発で多数のリクエストを並列送信して、処理速度やスループットなどの統計を出してくれます。
以下のコマンドを実行します。
ab -n 1000 -c 1000 -s 120 http://127.0.0.1:8000/api/customers/
ただツールで1000件のリクエストで投げても以下のエラーが出ました。
This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
apr_socket_recv: Connection reset by peer (54)
Total of 1 requests completed
ローカルでの環境になり、処理ができずサーバ側がコネクションを即切りになっていました。
なので100リクエストにすると処理ができました。
ab -n 100 -c 100 -s 120 http://127.0.0.1:8000/api/customers/
以下が実行ログになります。
This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: WSGIServer/0.2
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /api/customers/
Document Length: 97 bytes
Concurrency Level: 100
Time taken for tests: 30.122 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 42700 bytes
HTML transferred: 9700 bytes
Requests per second: 3.32 [#/sec] (mean)
Time per request: 30122.204 [ms] (mean)
Time per request: 301.222 [ms] (mean, across all concurrent requests)
Transfer rate: 1.38 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.2 1 2
Processing: 12 6406 7835.1 4061 30109
Waiting: 10 6403 7835.2 4054 30108
Total: 12 6408 7835.2 4062 30111
Percentage of the requests served within a certain time (ms)
50% 4062
66% 4076
75% 12069
80% 12083
90% 12092
95% 30110
98% 30111
99% 30111
100% 30111 (longest request)
ツールは他にもありますが、今回は以上にしておきます。
まとめ
- curl の並列処理では、ローカルAPIに対して1000回のリクエストをほぼ同時に送ることができ、全てのリクエストが正常に完了しました。短時間で簡易的に負荷をかける場合には有効な方法です。
- ApacheBenchで1000並列を試したところ、サーバ側がコネクションを即時切断し、ほとんどのリクエストが失敗しました。これはローカル環境では処理能力や同時接続数が追いつかないためと考えられます。
- 並列数を100に下げると全てのリクエストが完了し、失敗はありませんでしたが、平均応答時間が長くなりました。ローカル環境やサーバの設定(ワーカー数、DB接続プールなど)が処理性能に影響していることが確認できました。
- 今回は curlとApacheBenchのみを使用しましたが、一定のレートでリクエストを送りたい場合や、より詳細な負荷試験を行いたい場合はwrk2やheyなどのツールも有効です。
次回はTiFlashを使って高速化を行なっていきます。
Discussion