数据库连接池数量测试
线程数量设置的地方有3个,业务线程池 数据库连接池 数据库最大线程数
数据库最大线程数设置为500,只是为了不让连接池数量大于这个数,可无视这个数
测试代码,一个查询语句 一个update语句.
查询语句无论怎么测试区别不是很明显 就先不去讨论这个,或者后面我再测试下.
代码:
public class SqlThread {
@Autowired
IUserDao userDao;
@Test
public void test() throws InterruptedException {
int size = 10000;
List<Callable<Object>> list = new ArrayList<Callable<Object>>();
for (int i = 0; i < size; i++) {
list.add(new Callable<Object>() {
@Override
public Object call() throws Exception {
userDao.execute("update user set level = ? where uid = ?",
1, 1);
return null;
}
});
}
long l = System.nanoTime();
List<Future<Object>> futureList = ScheduledHelper.regScheduler
.invokeAll(list);
System.out.println("耗时(ms):" + (System.nanoTime() - l) / 1000 / 1000);
}
}
测试数据:
-----------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 第二次 15
100业务线程
耗时(s):30 第二次 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% 1w次
如果忽略掉测试的误差.
在这样大的计算压力下基本上可以看出连接池在70左右.业务线程在大于连接池的情况下才能充分利用性能
同样的连接池,业务线程如果过小 或者过大 都会影响性能.
结论是,业务线程数量要大于连接池数量, 业务线程相同,连接池数量在100左右为最佳.
测试的时候mysql数据库 cpu没有多少变化 3-4%的样子,java cpu达到了70%+
这点看来没有发挥出mysql的性能! 这点看来得优化下