第 11 章调整 CPU 和内存资源大小的概念

使用此选项作为调整产品环境的起点。根据您的负载测试，根据需要调整您的环境值。

11.1. 性能建议

警告

当扩展到更多 Pod （因为额外的开销）并使用跨数据中心设置（因为额外的流量和操作）时，性能会降低。
当红帽构建用于长时间的 Keycloak 实例时，增加的缓存大小可以提高性能。这将减少响应时间并减少数据库的 IOPS。仍然需要在实例重启时填充这些缓存，因此不要根据缓存填写后测量的稳定状态设置资源。
使用这些值作为起点，并在进入生产环境前执行您自己的负载测试。

Summary：

建议：

Pod 的基本内存用量，包括 Realm 数据和 10,000 个缓存会话的缓存 1250 MB RAM。
在容器中，Keycloak 为基于堆的内存分配 70% 的内存限值。它还将使用大约 300 MB 的非堆内存。要计算请求的内存，请使用上面的计算。作为内存限制，从上面的值中减去非堆内存，并将结果除以 0.7 划分。
对于每秒 15 个基于密码的用户登录，请将 1 个 vCPU 分配给集群（每秒测试最多 300 个）。
红帽构建的 Keycloak 使用大多数 CPU 时间哈希为用户提供的密码，并与哈希迭代数量成比例。
对于每个 200 个客户端凭证，每秒授予 1 个 vCPU 到集群（每秒测试最多 2000 个）。
大多数 CPU 时间都会创建新的 TLS 连接，因为每个客户端仅运行一个请求。
对于每个 120 每秒刷新令牌请求，1 个 vCPU 到集群（每秒测试最多为 435 刷新令牌请求）。
保留 150% 额外头条以便 CPU 使用量处理负载高峰。这样可确保节点快速启动，并有足够的容量来处理故障转移任务。当其 Pod 在我们的测试中节流时，红帽构建的 Keycloak 的性能会显著下降。

Red Hat build of Keycloak （默认情况下，在数据库中存储用户会话）需要以下资源在 Aurora PostgreSQL 多AZ 数据库中获得最佳性能：

每个 100 个登录/logout/refresh 请求每秒：

vCPU 要求作为范围提供，因为数据库主机上的 CPU 饱和度增加，每个请求的 CPU 使用量会降低，响应时间会增加。数据库上的 CPU 配额较低，可能会导致高峰负载期间的响应时间较慢。如果在峰值负载期间快速响应时间至关重要，请选择较大的 CPU 配额。请参见以下示例。

目标大小：

计算的限制：

每个 Pod 请求的 CPU: 3 个 vCPU
（每秒45 个登录 = 3 个 vCPU，600 个客户端凭证授予每秒授予 3 个 vCPU，345 刷新令牌 = 3 个 vCPU。总和最多 9 个 vCPU。当集群中运行的 3 个 Pod 时，每个 Pod 都会请求 3 个 vCPU。
每个 Pod 的 CPU 限制： 7.5 vCPU
（允许额外的 150% CPU 处理峰值、启动和故障转移任务）
每个 Pod 请求的内存： 1250 MB
(1250 MB 基本内存)
每个 Pod 的内存限值： 1360 MB
(1250 MB 预期内存使用减 300 非堆使用，以 0.7 划分)
Aurora Database 实例： db.t4g.large 或 db.t4g.xlarge，具体取决于高峰负载期间所需的响应时间。
（每秒45 个登录，每秒 5 个退出一次，360 每秒刷新令牌。这个总和每秒 410 请求。这个预期 DB 使用为 1.4 到 2.8 vCPU，DB 闲置负载为 0.3 vCPU。这表示 2 个 vCPU db.t4g.large 实例或 4 个 vCPU db.t4g.xlarge 实例。如果在高峰使用期间允许响应时间更高，则 2 个 vCPU db.t4g.large 将更具成本效益。在我们的测试中，当 CPU 饱和达到了这个场景的 2 个 vCPU db.t4g.large 实例时，登录的介质和令牌刷新增加了 120 毫秒。为了在高峰使用期间更快的响应时间，请针对这种情况考虑 4 个 vCPU db.t4g.xlarge 实例。）

要创建在 AWS 区域中使用两个 AZ 的主动-主动 Keycloak 设置大小，请按照以下步骤操作：

根据 CPU 请求和限值的大小，根据预期的故障转移行为，有不同的方法：

快速故障转移和成本更高: 为第二个站点保留 CPU 请求和限值。这样，任何剩余的站点都可以立即接管主站点的流量，而无需扩展。
故障转移速度较慢，更具成本效益: 为第二个站点减少 CPU 请求和限值，超过 50%。当其中一个站点失败时，将剩余的站点从 3 个 Pod 扩展到 6 个 Pod，也可以手动、自动化或使用 Horizontal Pod Autoscaler。这需要在集群或集群自动扩展功能上有足够的备用容量。
某些环境的备用设置: 为第二个站点将 CPU 请求减少 50%，但会保留以上 CPU 限值。这样，其余站点就可以获取流量，但只有在节点遇到 CPU 压力时，才会遇到 CPU 压力，因此在高峰流量期间的响应时间较慢。此设置的好处是，在故障切换过程中不需要扩展 Pod 的数量，这更易于设置。