2025-05-13 13:29
@zzutligang 你这个信息也没有异常的表象。152是说明你们java应用服务器 CPU线程的性能也就这些了druid设置再大也没意义。目前不知道你这是啥原因,还是得压测进行定位问题,我们2H4G的小云服务器都能压住1500的并发冒烟,你这32H64G不应该
2025-05-12 19:22
JF默认不支持这样的路由,里面就是map的get高效key匹配。
扩展支持:
方案1:自定义ActionHandler,里面按需要的业务进行匹配url
https://jfinal.com/doc/2-7
configHandler 》 me.setActionHandler
(推荐)方案2:设置扩展 ActionMapping,按自己业务进行匹配url
https://jfinal.com/doc/2-2
configConstant 》me.setActionMapping 》继承ActionMapping 重写getAction 方法支持自己的业务。 具体的业务实现代码,可以问AI 上面字符串匹配与参数提取方式,会给出正则表达式实现
2025-05-08 13:42
@zzutligang 还是得压测一下,连接池数太大也够呛,CPU也忙不过来。。。看你服务器内存够大,多用下缓存工具,像下拉框等数据用缓存就比较好。Redis能上的也上下性能是真强
2025-05-08 09:06
32H62G服务器,用户大约5千人,这个也需要看情况,是否同时使用的场景,是否一个页面打开会请求多个需要数据库连接的业务。
如果是5千人同时使用,那100个数据库连接明显不够使用。比如5千个获取数据库连接的请求,同时只有100个在操作了,那还有4900个在等待了。 一个请求比如用1秒,得一分钟左右才能处理完,等待都超时了或全卡主了。
实际情况可能比这个时间还要长,得用压测看下实际情况。Arthas CPU火焰图可以看见占用的时间。
上面sioui说的也是一个问题,数据库是自安装的还是云数据库服务,自安装的需要配置连接数,如果连接数比java这边少肯定是不行的,连接溢出了,druid设置的最大连接数也没意义。或数据库设置的超时数比druid设置要小,也不行。
排查的话,就晚上(客户不用的时候)用Arthas CPU火焰图监控开启,jmeter编写一个模拟的业务流,用系统里面的用户登录模拟业务进行访问压测。
2025-04-28 13:06
@canca 不影响,我们线上也有 Tomcat 项目,日志应该是让运维关了。开发时会提示忽略就行
2025-04-19 16:26
你可能是需要setTimeBetweenConnectErrorMillis 这个方法(配置发生错误时多久重连)。
PS:如果需要的 set 方法DruidPlugin没有实现时,可以自行调用DruidDataSource ds 对象。
示例代码:
DruidPlugin dp = new DruidPlugin(url, name, pwd){
@Override
public boolean start() {
if (super.start()){
this.ds.setConnectionErrorRetryAttempts(10);//控制连接失败重试次数
this.ds.setBreakAfterAcquireFailure(true);//失败后终止重试
this.ds.setMaxWait(1000 * 10);//10秒超时
}
return true;
}
};
补充:
还可以DruidPlugin addFilter加监控 累计错误次数,然后做相应的处理,比如关闭DruidPlugin,通知负责人之类的业务。
或者增加自定义任务器,定期检查数据库的健康情况,长期不访问的租户做关闭连接池操作,下次访问时再启动即可(如果配置不对自然也启动不了)
2025-04-17 21:27
@zzutligang 禁用autoType 你测试后反馈一下社区里,我没做过测试
2025-04-15 11:39
@北流家园网 _MappingKit 可以把字段映射拆分出来,让其调用另一个 Java 类,可在_MappingKit 保持干净只映射表关系,字段映射调用另一个类即可。 mapping_kit_template.jf 随便改造嘛
2025-04-15 11:36
@北流家园网 表越多,越应该使用这个 模式,因为映射关系在生成_MappingKit 时已经提前Java代码级配置好了。 在 JF 启动时,直接代码运行映射关系。加载速度和数据库查询后映射关系,性能完全不能比不在一个维度。