性能文章>注意:两个会导致druid性能下降10倍的参数>

注意:两个会导致druid性能下降10倍的参数原创

1年前
8069314

druid:阿里巴巴开源的为监控而生的数据库连接池。你看,官方都没有说是高性能数据库连接池,因为,在性能方面,HikariCP会说:我不是针对谁,论性能,在坐的各个数据库连接池都是渣渣。Github HikariCP的介绍:A solid, high-performance, JDBC connection pool at last。而且HikariCP还是springboot2.x以后默认的数据库连接池。

HikariCP性能参考–图片来自于HikariCP Github主页:

image.png

ConCycle就是指DataSource.getConnection()、Connection.close()。而StatementCycle就是指Connection.prepareStatement()、Statement.execute()、Statement.close()。需要说明的是HikariCP Github没有给出和druid的对比,不过,也有网友对这两个中间件进行了压测比较,只对比性能的前提下,HikariCP还是要好不少的。

不过,即使druid的性能不是最好的,还是有很多项目组或者公司选择druid。因为,它的监控非常非常完善。我们项目组也不例外,用的是druid。

可能很多项目的很多中间件的配置,都不是非常合理,没有经过充分的压测。比如Redis相关,数据库相关,MQ相关等。笔者的这个使用druid的项目也不例外,笔者今天介绍4个你可能不怎么关注的参数:

  • validationQuery

用来检测连接是否有效的sql,如果validationQuery为空,那么testOnBorrow、testOnReturn、testWhileIdle这三个参数都不会起作用,因为这三个参数都是通过执行参数validationQuery指定的SQL来验证数据库连接的有效性,配置参考:validationQuery=SELECT 1

  • testWhileIdle

建议配置为true。对性能影响很小,因为是定期检查。如果连接空闲时间大于timeBetweenEvictionRunsMillis指定的毫秒,就会执行参数validationQuery指定的SQL来检测连接是否有效。

  • testOnBorrow

建议配置为false。获取连接时执行validationQuery检测连接是否有效,这个配置会降低性能。

  • testOnReturn

建议配置为false。归还连接时执行validationQuery检测连接是否有效,这个配置会降低性能。

如果这4个参数都是按照笔者建议进行配置,那么就不会有什么性能问题,但是。请看下面这张压测表格–testOnReturn和testOnBorrow不同值组合的情况下,5000次主键查询的耗时比较:

image.png

惊不惊喜,意不意外???

由这张压测结果表,我们可以得出如下结论:

  1. testOnReturn和testOnBorrow都为false时性能最好。

  2. 如果任意一个参数为true(另一个为false),会导致性能下降5倍多

  3. testOnReturn和testOnBorrow对性能的影响几乎一样(因为它们都会通过执行参数validationQuery指定的SQL来校验连接的有效性)。

事实上,这两个参数在druid中默认值就是false。所以,赶紧去检查你们的配置,是不是和笔者一样,多此一举的将它们配置为true。

请先登录,再评论

如果这4个参数都是按照笔者建议进行配置,那么就不会有什么性能问题,但是。请看下面这张压测表格–testOnReturn和testOnBorrow不同值组合的情况下,5000次主键查询的耗时比较:

1.这里5000次是qps?如果不是时间间隔多久?
2.表数据有多少行?
3.还有12345,是反复进行了5次嘛

1年前

飞哥还是一如既往的优秀😃

1年前

这个之前druid官方有推最佳配置,就是建议配置false的😁

1年前

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得