From cf2e2b692b8649f4158d943e413be8be30ce322e Mon Sep 17 00:00:00 2001 From: Pedro Ruivo Date: Tue, 29 Oct 2024 13:25:42 +0000 Subject: [PATCH] Update sizing guide for client credential grant Closes #34347 Signed-off-by: Pedro Ruivo Signed-off-by: Alexander Schwartz Signed-off-by: Alexander Schwartz Co-authored-by: Alexander Schwartz Co-authored-by: Alexander Schwartz --- .../high-availability/concepts-memory-and-cpu-sizing.adoc | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/guides/high-availability/concepts-memory-and-cpu-sizing.adoc b/docs/guides/high-availability/concepts-memory-and-cpu-sizing.adoc index 1dab02bf32..f94a62779c 100644 --- a/docs/guides/high-availability/concepts-memory-and-cpu-sizing.adoc +++ b/docs/guides/high-availability/concepts-memory-and-cpu-sizing.adoc @@ -47,6 +47,10 @@ Most CPU time goes into creating new TLS connections, as each client runs only a This ensures a fast startup of the node, and sufficient capacity to handle failover tasks. Performance of {project_name} dropped significantly when its Pods were throttled in our tests. +* When performing requests with more than 2500 different clients concurrently, not all client information will fit into {project_name}'s caches when those are using the standard cache sizes of 10000 entries each. +Due to this, the database may become a bottleneck as client data is reloaded frequently from the database. +To reduce the database usage, increase the `users` cache size by two times the number of concurrently used clients, and the `realms` cache size by four times the number of concurrently used clients. + {project_name}, which by default stores user sessions in the database, requires the following resources for optimal performance on an Aurora PostgreSQL multi-AZ database: For every 100 login/logout/refresh requests per second: