834ef79509
The content was moved over from the Keycloak Benchmark subproject. Closes #24844 Signed-off-by: Alexander Schwartz <aschwart@redhat.com> Co-authored-by: Pedro Ruivo <pruivo@redhat.com> Co-authored-by: Michal Hajas <mhajas@redhat.com> Co-authored-by: Kamesh Akella <kakella@redhat.com> Co-authored-by: Ryan Emerson <remerson@redhat.com> Co-authored-by: Anna Manukyan <amanukya@redhat.com> Co-authored-by: Thomas Darimont <thomas.darimont@googlemail.com> Co-authored-by: Stian Thorgersen <stian@redhat.com> Co-authored-by: Thomas Darimont <thomas.darimont@googlemail.com> Co-authored-by: AndyMunro <amunro@redhat.com>
7 lines
671 B
Text
7 lines
671 B
Text
For the best performance, the values for the initial, minimal and maximum database connection pool size should all be equal.
|
|
This avoids creating new database connections when a new request comes in which is costly.
|
|
|
|
Keeping the database connection open for as long as possible allows for server side statement caching bound to a connection.
|
|
In the case of PostgreSQL, to use a server-side prepared statement, https://jdbc.postgresql.org/documentation/server-prepare/#activation[a query needs to be executed (by default) at least five times].
|
|
|
|
See the https://www.postgresql.org/docs/current/sql-prepare.html[PostgreSQL docs on prepared statements] for more information.
|