数据库连接池数量测试

线程数量设置的地方有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业务线程

耗时(ms):663 597

耗时(s):58 耗时(s):336 ?

140

耗时(s):138

240

耗时(s):144

440

耗时(s):180

100业务线程 1/10

耗时(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的性能! 这点看来得优化下

数据库连接池数量测试

猜你喜欢