-
Seems reasonable.
I sometime wonder if we shouldn't switch to HikariCP (https://github.com/brettwooldridge/HikariCP; quite tiny [150K], compatible licence). They seem to be quite focused on performance and has this tidbid there: https://github.com/brettwooldridge/HikariCP?tab=readme-ov-file#youre-probably-doing-it-wrong:
AKA "What you probably didn't know about connection pool sizing". Watch a video from the Oracle Real-world Performance group, and learn about why connection pools do not need to be sized as large as they often are. In fact, oversized connection pools have a clear and demonstrable negative impact on performance; a 50x difference in the case of the Oracle demonstration. Read on to find out. (https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)
Type |
Improvement
|
Priority |
Normal
|
Assignee | |
Version |
none
|
Sprints |
n/a
|
Customer |
n/a
|
Currently we calculate size of the repo-pool based on the available CPUs which could result error on machines with better specification:
The problem stems from the fact that MySQL by default has limit of 151 connections (https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_connections) and on bigger machines (like 40 CPU cores or more) we would have gigantic pool.
I think, even on bigger machine, we should have some sane maximum instead of going for "sky is the limit".
Relevant code