第 15 章 CPU 和内存资源大小的概念
将此用作调整产品环境大小的起点。根据您的负载测试，根据需要调整您的环境的值。
15.1. 性能建议
- 当扩展到更多 Pod （由于额外的开销）和使用跨数据中心设置（因为额外的流量和操作）时，性能会降低。
- 当红帽构建 Keycloak 实例时，增加的缓存大小可以提高性能。这将减少响应时间并减少数据库的 IOPS。仍然需要在实例重启时填充这些缓存，因此不要根据缓存填充后测量的稳定状态设置资源。
- 使用这些值作为起点，并在进入生产前执行您自己的负载测试。
Summary：
- 使用的 CPU 会线性扩展，请求数量最高为以下测试的限制。
- 使用的内存会线性扩展，且活跃会话数量达到以下测试的限制。
建议：
- 非活动 Pod 的基本内存用量为 1000 MB RAM。
对于每个 100,000 个活跃的用户会话，在三节点集群中添加 500 MB 的每个 Pod （测试最多 200,000 个会话）。
这假定每个用户仅连接到一个客户端。内存要求随着每个用户会话的客户端会话数量（尚未测试）增加。
- 在容器中，Keycloak 为基于堆的内存分配 70% 的内存限值。它还将使用大约 300 MB 的非堆内存。要计算请求的内存，请使用上面的计算。作为内存限制，从上面的值中减去非堆内存，并将结果分为 0.7。
对于每 8 个基于密码的用户登录，在三节点集群中，每个 Pod 的每个 Pod 1 个 vCPU （每秒测试最多 300 个）。
红帽构建的 Keycloak 将大多数 CPU 时间哈希处理了用户提供的密码，它与哈希迭代数量成比例。
对于每个 450 客户端凭证，每个 Pod 在三个节点集群中每秒授予 1 个 vCPU （每秒测试最多 2000 个）。
大多数 CPU 时间都要创建新的 TLS 连接，因为每个客户端仅运行单个请求。
- 对于每个 350 刷新令牌请求，三个集群中每个 Pod 的 1 个 vCPU （测试一次为 435 个刷新令牌请求）。
- 将 200% 的额外头空间留给 CPU 使用量，以处理负载中的高峰。这样可确保节点的快速启动，并有足够的容量来处理故障转移任务，例如在一个节点失败时重新平衡 Infinispan 缓存。当我们的测试中节流时，红帽构建的 Keycloak 的性能会显著下降。
15.1.1. 计算示例
目标大小：
- 50,000 个活跃的用户会话
- 每秒 24 次登录
- 450 客户端凭证每秒授予
- 350 刷新令牌请求每秒
计算的限制：
请求的 CPU：5 个 vCPU
（每秒的24 登录 = 3 个 vCPU，450 客户端凭据会每秒授予 1 个 vCPU，350 刷新令牌 = 1 个 vCPU）
CPU 限制：15 个 vCPU
（允许 CPU 请求处理峰值、启动和故障转移任务的三倍。）
请求内存：1250 MB
(1000 MB 基础内存，以及 50,000 个活动会话的 250 MB RAM)
内存限制：1360 MB
(1250 MB 预期内存使用量减去 300 个非堆使用，除以 0.7 为单位)
