データベース接続プール数テスト
2881 ワード
詳細
スレッド数が設定されている場所は3つあり、ビジネススレッドプールデータベース接続プールデータベースの最大スレッド数
データベースの最大スレッド数は500に設定されていますが、接続プールの数がこの数より大きくならないように、この数は無視できます.
テストコード、クエリー文、update文.
クエリー文はどのようにテストしても区別がはっきりしないので、先にこれを議論しないか、後でテストします.
コード:
テストデータ:
-----------update user set .............
100ビジネススレッド
20
消費時間(ms):663 597
70
消費時間(s):58消費時間(s):336?
140
消費時間(s):138
240
消費時間(s):144
440
消費時間(s):180
100ビジネススレッド1/10
70
消費時間(s):9
240
時間(s):8
340
時間(s):8
70データベーススレッド1/10
10ビジネススレッド
消費時間(s):37
50ビジネススレッド
消費時間(s):12
100ビジネススレッド
消費時間(s):9
200ビジネススレッド
消費時間(s):9
300ビジネススレッド
消費時間(s):9
50データベーススレッド1/10
25ビジネススレッド
消費時間(s):31
50ビジネススレッド
時間(s):21 2回目15
100ビジネススレッド
時間(s):30 2回目39
200ビジネススレッド
消費時間(s):27
30スレッド
50接続プール
消費時間(ms):11 492
70接続プール
消費時間(ms):11 991
100スレッド
50接続プール
消費時間(ms):9 422
70接続プール
消費時間(ms):7 379
200接続プール
消費時間(ms):6 947
300接続プール
消費時間(ms):6 781
450接続プール
消費時間(ms):6 865
300スレッド
100接続プール
消費時間(ms):7 682
300接続プール
消費時間(ms):9,250
テストの目的は、現在のデータベースのソフト・ハードウェア構成環境において、接続プール数とビジネス・スレッド数の変化によるパフォーマンスの影響、実行遅延の変化を探ることです.
表を作成していない、標準的な数字がないのはデータベース接続プールの数で、1/10はテストデータ量が初めての10%1 w回であることを示している.
テストの誤差を無視すると.
このような大きな計算圧力では、接続プールが70程度であることが基本的にわかる.ビジネス・スレッドは、接続プールよりも大きい場合にパフォーマンスを十分に活用できます.
同じ接続プールでは、ビジネススレッドが小さすぎるか、大きすぎるとパフォーマンスに影響します.
結論として、業務スレッド数は接続プール数より大きく、業務スレッドは同じで、接続プール数は100程度が最適である.
テスト時にmysqlデータベースcpuはあまり変わらず3-4%の様子でjava cpuは70%+に達しました
この点はmysqlの性能を発揮していないようです!この点は最適化されているようだ.
スレッド数が設定されている場所は3つあり、ビジネススレッドプールデータベース接続プールデータベースの最大スレッド数
データベースの最大スレッド数は500に設定されていますが、接続プールの数がこの数より大きくならないように、この数は無視できます.
テストコード、クエリー文、update文.
クエリー文はどのようにテストしても区別がはっきりしないので、先にこれを議論しないか、後でテストします.
コード:
public class SqlThread {
@Autowired
IUserDao userDao;
@Test
public void test() throws InterruptedException {
int size = 10000;
List> list = new ArrayList>();
for (int i = 0; i < size; i++) {
list.add(new Callable
テストデータ:
-----------update user set .............
100ビジネススレッド
20
消費時間(ms):663 597
70
消費時間(s):58消費時間(s):336?
140
消費時間(s):138
240
消費時間(s):144
440
消費時間(s):180
100ビジネススレッド1/10
70
消費時間(s):9
240
時間(s):8
340
時間(s):8
70データベーススレッド1/10
10ビジネススレッド
消費時間(s):37
50ビジネススレッド
消費時間(s):12
100ビジネススレッド
消費時間(s):9
200ビジネススレッド
消費時間(s):9
300ビジネススレッド
消費時間(s):9
50データベーススレッド1/10
25ビジネススレッド
消費時間(s):31
50ビジネススレッド
時間(s):21 2回目15
100ビジネススレッド
時間(s):30 2回目39
200ビジネススレッド
消費時間(s):27
30スレッド
50接続プール
消費時間(ms):11 492
70接続プール
消費時間(ms):11 991
100スレッド
50接続プール
消費時間(ms):9 422
70接続プール
消費時間(ms):7 379
200接続プール
消費時間(ms):6 947
300接続プール
消費時間(ms):6 781
450接続プール
消費時間(ms):6 865
300スレッド
100接続プール
消費時間(ms):7 682
300接続プール
消費時間(ms):9,250
テストの目的は、現在のデータベースのソフト・ハードウェア構成環境において、接続プール数とビジネス・スレッド数の変化によるパフォーマンスの影響、実行遅延の変化を探ることです.
表を作成していない、標準的な数字がないのはデータベース接続プールの数で、1/10はテストデータ量が初めての10%1 w回であることを示している.
テストの誤差を無視すると.
このような大きな計算圧力では、接続プールが70程度であることが基本的にわかる.ビジネス・スレッドは、接続プールよりも大きい場合にパフォーマンスを十分に活用できます.
同じ接続プールでは、ビジネススレッドが小さすぎるか、大きすぎるとパフォーマンスに影響します.
結論として、業務スレッド数は接続プール数より大きく、業務スレッドは同じで、接続プール数は100程度が最適である.
テスト時にmysqlデータベースcpuはあまり変わらず3-4%の様子でjava cpuは70%+に達しました
この点はmysqlの性能を発揮していないようです!この点は最適化されているようだ.