PgBouncer簡易テスト
3613 ワード
テスト環境、ノート4コア8スレッド16 Gメモリ、PostgreSQL v 9.4.5 EDBから取得
デフォルトパラメータテスト(shared_buffer 128 M)
1、初期化
開始時は計時されず、全過程で約10分程度、実行後dataディレクトリは15.8 G
2、PostgreSQLのテスト
64個のセッション8スレッドを有効にし、各セッションが6個のトランザクションを完了した後に終了します.
これは私が取った最低の結果で、正常な結果は180頭で、たまに190以上で、200を超えたことがありません.
2、PgBouncerをテストする
同様に最低結果で、最高は232を超え、大部分の結果は220余りで、昇進が明らかであることがわかる.
キャッシュアップテスト(shared_buffer 1 G)
1、PostgreSQL試験方法同上
同じ最小値で、次のようになります.
2、PgBouncer試験方法同上
上は最高値と最低値で、大キャッシュ、データベース容量がメモリに相当する場合、全体的に向上することはありません.
データベースを再初期化し、10倍のデータ量を生成
ノートパソコンのハードディスク(HDD)なので、初期化はほぼ3時間です
仕事が多すぎて、結果を記録していないので、効果もあります.上昇幅は上のテストとあまり違いません.
最大のギャップ
-Cパラメータからは、トランザクションごとに新しい接続が割り当てられます.この場合、PG forkプロセスがもたらす追加のシステム支出の影響は非常に顕著で、パフォーマンスの差は2倍以上です.
デフォルトパラメータテスト(shared_buffer 128 M)
1、初期化
./pgbench -i -s 1000 postgres
開始時は計時されず、全過程で約10分程度、実行後dataディレクトリは15.8 G
2、PostgreSQLのテスト
64個のセッション8スレッドを有効にし、各セッションが6個のトランザクションを完了した後に終了します.
[quanzl@bogon bin]$ ./pgbench -j 8 -c 64 -t 6 postgres -p 5432
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 64
number of threads: 8
number of transactions per client: 6
number of transactions actually processed: 384/384
latency average: 0.000 ms
tps = 174.962183 (including connections establishing)
tps = 176.286241 (excluding connections establishing)
[quanzl@bogon bin]$
これは私が取った最低の結果で、正常な結果は180頭で、たまに190以上で、200を超えたことがありません.
2、PgBouncerをテストする
[quanzl@bogon bin]$ ./pgbench -j 8 -c 64 -t 6 popo1 -p 5431
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 64
number of threads: 8
number of transactions per client: 6
number of transactions actually processed: 384/384
latency average: 0.000 ms
tps = 214.251520 (including connections establishing)
tps = 214.912432 (excluding connections establishing)
[quanzl@bogon bin]$
同様に最低結果で、最高は232を超え、大部分の結果は220余りで、昇進が明らかであることがわかる.
キャッシュアップテスト(shared_buffer 1 G)
1、PostgreSQL試験方法同上
[quanzl@bogon bin]$ ./pgbench -j 8 -c 64 -t 6 postgres -p 5432
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 64
number of threads: 8
number of transactions per client: 6
number of transactions actually processed: 384/384
latency average: 0.000 ms
tps = 184.817262 (including connections establishing)
tps = 186.272290 (excluding connections establishing)
[quanzl@bogon bin]$
同じ最小値で、次のようになります.
tps = 199.936374 (including connections establishing)
tps = 201.550601 (excluding connections establishing)
tps = 208.001447 (including connections establishing)
tps = 209.930247 (excluding connections establishing)
tps = 190.078591 (including connections establishing)
tps = 191.643495 (excluding connections establishing)
tps = 217.580382 (including connections establishing)
tps = 219.527798 (excluding connections establishing)
tps = 196.842624 (including connections establishing)
tps = 198.330960 (excluding connections establishing)
tps = 214.633296 (including connections establishing)
tps = 216.626217 (excluding connections establishing)
2、PgBouncer試験方法同上
[quanzl@bogon bin]$ ./pgbench -j 8 -c 64 -t 6 popo1 -p 5431
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 64
number of threads: 8
number of transactions per client: 6
number of transactions actually processed: 384/384
latency average: 0.000 ms
tps = 225.172794 (including connections establishing)
tps = 225.775740 (excluding connections establishing)
[quanzl@bogon bin]$
tps = 197.430422 (including connections establishing)
tps = 197.920393 (excluding connections establishing)
上は最高値と最低値で、大キャッシュ、データベース容量がメモリに相当する場合、全体的に向上することはありません.
データベースを再初期化し、10倍のデータ量を生成
ノートパソコンのハードディスク(HDD)なので、初期化はほぼ3時間です
仕事が多すぎて、結果を記録していないので、効果もあります.上昇幅は上のテストとあまり違いません.
最大のギャップ
-Cパラメータからは、トランザクションごとに新しい接続が割り当てられます.この場合、PG forkプロセスがもたらす追加のシステム支出の影響は非常に顕著で、パフォーマンスの差は2倍以上です.