使用 Google 负载均衡器实现最大 QPS

Question

在 GCP 中文档，Google 声称每秒最多可支持 100 万次查询。然而，作为项目的一部分，我的团队决定同时测试区域 HTTPS LB 和全球 HTTPS LB。

n2d-highcpu-64以下是我们使用 7 个客户端对 4 个虚拟机获取随机密钥所获得的一些结果2TB - SSD Persistent Disk。对于 30 秒和 4300 个长持续连接；

1. 如果没有负载均衡器，每个实例平均返回680k qps。
2. 使用区域 HTTPS 负载均衡器以 4vms 作为后端服务，结果约为150k qps。
3. 使用具有相同 4vms 且没有 Cloud Armor 的全局 HTTPS 负载均衡器，其平均值为205k qps。

我的问题如下：

1. 负载均衡器配置中是否存在任何导致出现这种限制的因素？

2. 是否有一些关于使用负载均衡器实现至少 100 万 qps 的推荐架构或最佳实践的文档？

结果截图

结果截图

Answer 1

Google Cloud 的百万连接测试（也可以看看带脚本的注释) 使用了相当多的实例。64 个虚拟机作为客户端，200 个 Web 服务器虚拟机后端。每个实例 5000 个 rps 使后端保持可管理的较小规模，从而降低了扩大规模挑战的可能性。

考虑 TCP/UDP 端口耗尽。如果源 IP、目标 IP 和目标端口保持不变，则套接字的源端口只有 50k 到 60k 个。

确认不使用负载平衡器的测试实际上经过与远程测试相同的 IP 堆栈。建立套接字、创建数据包以及执行网络堆栈操作会产生开销。

测量查询和网络的延迟。每秒一百万意味着查询需要在所有服务过程中以微秒为单位进行处理。与留在机器上的几乎为零的延迟相比，即使是相对较小的网络延迟也会大大降低吞吐量。

然而，一百万个请求并不是一个有用的营销数字。它没有做任何实际工作：“每个 Web 响应的大小为 1 个字节，不包括 http 标头。”实际上，在达到神话般的一百万之前，执行某些操作会耗尽其他资源，如存储 IOPS、内存或 CPU。

根据当前应用程序的使用情况和组织规划，量化您需要的 qps 或连接数。在容量规划时，可以随意四舍五入，但如果没有理由，乘以 100 倍或 1000 倍则毫无意义。

从规模上看，这个 Stack Exchange 网络通常能够成为互联网上流量最大的网站。但是并发 WebSockets最大“仅”约为 600,000。负载均衡器峰值为每秒 4,500 个请求。每秒 100 万个请求则要大得多。