Repository navigation
Replies: 1 comment 6 replies
|
@rcollette - did you find any workaround for the problem? we are getting same issue during load testing. keycloak is not respecting the --db-pool-max-size command line parameter. |
|
Unfortunately, that didn't work for us either. I created a separate thread as I am getting a bit different error from db, but reason is same - #16153 |
|
Actually, we just did a test setting the connection pool to 40 while the database supports over 60, and loaded it with three machines running 20 threads each. We no longer got sql connection errors and the connections to the server peaked at 40. So it would appear that the connection pool configuration is being honored. However, we were getting connection timeout errors on the client side and no errors on the server. I would prefer to send some sort of error to the client when the server cannot respond in a reasonable amount of time, such as a 503 and get an error log for that. With the current behavior, clients won't get serviced but we have no indication of a problem from the server. |
|
That is interesting, would you mind telling me what version of Quarkus keycloak you're using? Also which helm chart are you using to deploy? |
|
@rcollette, your trick of setting much lower number worked for me, I set max connections to 20 and I didn't get the pool error but I am getting timeout error |
|
It will be some time before I can respond. US holiday till Tuesday and India offline at the moment. My recollection is that we were seeing ConnectionTimeoutException in JMeter but JM FBD6 eter is supposed to wait forever by default so I am trying to get more details about the test setup and the errors that occurred. |
Uh oh!
There was an error while loading. Please reload this page.
In load testing we are hitting a "Too many connections" error when our HTTP request concurrency reaches the configured number of database connections in the the pool via the KC_DB_POOL_MAX_SIZE setting.
Test Setup
We observe in the AWS console that the database active connections maxes out at 62 connections.
At peak we see that there are "Too many connections" errors logged by Keycloak, which on the one hand probably indicates we need to make the connection pool smaller even though it is already smaller than MAX_CONNECTIONS but I would expect see far more HTTP requests being handled than the number of database connections in the pool.
If we change the test to run three clients with 15 threads each we see no errors.
It appears as though perhaps database connections are being established for the lifetime of the HTTP request, rather than opening and closing the connection for just the operations that involve the database. Typically database operations only require a small fraction of the overall request time and connections should be closed as soon as possible so that pooled connections can service many more HTTP requests than there are connections available.
Is there a way to improve this behavior to more effectively utilize available database connections? I have searched all content for "Too many connections" and "pool" and have not been able to find any guidance other than a request to allow configuration of request/worker thread pooling in https://github.com/keycloak/keycloak/issues/15224fa
All reactions