数据库连接池数量测试

线程数量设置的地方有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的性能! 这点看来得优化下