When users are managed in an external OIDC provider, gio am has to contact that provider during code generation/exchanges. Limiting to 10 connections means gio am has to reopen/closed connections when load exceeds the 10 kept connections in the pool: a performance penalty is observed both on gio and targeted provider (due to connections being constantly closed/reopened).
Other pool parameters would probably benefit in such scenarios such allowing to enable/tune HTTP/2 settings or enabling ALPN to autodetect HTTP/2 support which would allow to send multiple requests over a single connection.
In a stress case I have, we exceed the 10 connection pool limit whenever we reach 45 authentications/s per instance. As a consequence, this greatly limit gateway capacity to absorb the load. My test involves testing product up to 1500 authentifications/s so that would require more than 32 instances of gateway component to support that load with optimal response time.
π Feature
As a administrator
I want to be able to configure client http pool used to external providers
So that i can adjust it to the load
π Additional information
Current implementation hard-codes http client to 10 connections as in https://github.com/gravitee-io/gravitee-access-management/blob/master/gravitee-am-service/src/main/java/io/gravitee/am/service/http/WebClientBuilder.java#L60
When users are managed in an external OIDC provider, gio am has to contact that provider during code generation/exchanges. Limiting to 10 connections means gio am has to reopen/closed connections when load exceeds the 10 kept connections in the pool: a performance penalty is observed both on gio and targeted provider (due to connections being constantly closed/reopened).
Other pool parameters would probably benefit in such scenarios such allowing to enable/tune HTTP/2 settings or enabling ALPN to autodetect HTTP/2 support which would allow to send multiple requests over a single connection.
In a stress case I have, we exceed the 10 connection pool limit whenever we reach 45 authentications/s per instance. As a consequence, this greatly limit gateway capacity to absorb the load. My test involves testing product up to 1500 authentifications/s so that would require more than 32 instances of gateway component to support that load with optimal response time.
β Acceptance criteria
TBD
βοΈ Developer sub-tasks
TBD