MySQL 并发测试中,线程数和数据库连接池的实验

时间:2024-01-22 19:05:27

我一直以来,对性能测试中,连接池的大小要如何配置,不是太清楚;

就我所知道的,就DB自带对连接数的限制,在sqlserver中用select @@connection 可以查到,

在代码中,可以配置DB的连接池,

在中间件中,可以配置最大的线程数等等。

 

在性能测试中,这些配置显然很重要,要不然,木桶原理,哪一个低了,都是个性能瓶颈,在其他地方再怎么费力,也无能为力。

 

今天做了一个实验,不考虑中间件,不去考虑代码逻辑啊,接口调用什么的,只考虑数据库连接池,和实际并发数的影响。

工具也很简单,就用Jmeter中元件JDBC Connection Configuration配置DB连接数,再在JDBC请求中向表中新增一条记录。新增不像查询的,不会因为数据量的多少受影响。

 

 

因为线程数是受系统的用户数决定的,所以要分析受众数量,
可以通过以往的日志分析,一般系统中都会记录用户在何时,何种渠道,登录了,退出了,修改了,等等,总之是这样的交互表
通过分解,高峰时间段,以半小时,或每小时计算,每秒钟的最大用户数
也可以通过社会工程学,并叫上算法分析师,分析和计算出高峰期用户数量

还有一些是活动Campaign, 一段时间内的大促活动,比如双十一支付宝支付接口,比如商场活动促销,抢拍,秒杀,等等,
看看每秒钟的用户数量,能否大概掌握和预估一定的值;
比如我们这边,大促之前会通过短信或者微信的方式,通知我们的会员,在xxx链接领取优惠券,xxx时间可以积分兑换更多好礼,在xxx时候购买充值会员卡等等
分析有无裂变的方式,会引来更多会员,一般不太好控制,或者会故意将通知会员的速度调节慢些;
不可裂变,即用户即使转发链接给好友,好友不支持参与活动,这个时候,单位时间内能预估的会员就比较清楚。

分析活动短信或微信的转化率,即有百分之多少的会员,能够在收到通知后,立即点击链接来参与活动。
通常会有一个比例,但也有可能因为活动力度问题,比例不太一致。
总之,为了系统能文件运营,要用预估的峰值去跑。


而数据库的线程池: 可以根据预估的峰值,参考之后进行设置。

 

线程池的原理:

其实线程池的原理很简单,类似于操作系统中的缓冲区的概念,它的流程如下:
先启动若干数量的线程,并让这些线程都处于睡眠状态,当客户端有一个新请求时,就会唤醒线程池中的某一个睡眠线程,让它来处理客户端的这个请求,
当处理完这个请求后,线程又处于睡眠状态。

可能你也许会问:为什么要搞得这么麻烦,如果每当客户端有新的请求时,我就创建一个新的线程不就完了?
这也许是个不错的方法,因为它能使得你编写代码相对容易一些,但你却忽略了一个重要的问题?
那就是性能!

就拿我所在的单位来说,我的单位是一个省级数据大集中的银行网络中心,高峰期每秒的客户端请求并发数超过100,
如果为每个客户端请求创建一个新线程的话,
那耗费的CPU时间和内存将是惊人的,
如果采用一个拥有200个线程的线程池,
那将会节约大量的系统资源,使得更多的CPU时间和内存用来处理实际的商业应用,
而不是频繁的线程创建与销毁。

 

 先看以下图:

 

图中两次压测,并发数一样,数据库连接池不一样,上一个是10,下面的一个是100,并发数都是100,连接池大的时候,吞吐量要大很多。

并且由于并发数大于连接池,导致上面的错误率很高,大多数的错误原因是:

Cannot get a connection, pool error Timeout waiting for idle object

 

 

实验的结果

 

 

 

从第一次到第四次结果来看


当DB的最大连接数:当并发数<=最大链接数的时候,且启动时间慢,相当于请求来了,就能处理。
此时相等时间内的总请求数相近,吞吐量彼此相近。

当DB的最大链接> 当前并发数,且启动时间慢,
此时相等时间内的总请求数相近,吞吐量彼此相近。

 

一般来讲,现在都是前后端分离的系统,面向的是全网的受众,
我觉得启动时间,设置为1,比较合适;

 

 

当然,我这边没有去监控MySQL所在机器的CPU和内存情况。
第九次和第十次的结果也可以看出,并发数如果大于了DB连接数,
相同时间内,第九次的处理的总的请求数明显大于第十次,吞吐量自然也高;
第十次吞吐量比第九次低了很多,且错误率达到7%,错误原因是:
不需要总是不停的去进行上下文切换,

 

 第6次的失败原因:

Cannot create PoolableConnectionFactory (Communications link failure

The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.)