使用 Gatling 进行负载测试时 TLS 握手超时

Question

我目前在 AWS 中使用 Gatling 对我的服务进行负载测试。我使用 HTTP 进行了几次负载测试，我的服务运行良好。没有 TLS 握手错误。当我们转移到 HTTPS 时，负载测试结果显示到处都是 TLS 握手超时 异常，最终抛出 OOM，因为未处理的请求正在排队。

附加信息：

• 加特林机场景会是这样的： 发送三个请求并发送一个带有 connection: close header 的请求。我想模拟发送三个保持活动状态的请求并在最后关闭它。
• 我的服务由 Kubernetes 管理。

我做了什么：

• 我运行在其他Gatling实例上进行了负载测试，但错误仍然存​​在
• 重新启动了 AWS 负载均衡器。附加说明：没有 4xx 和 5xx 错误，但我们有客户端 TLS 协商错误。

我的问题：

1. 是否因为HTTPS需要初始握手而出现错误？
2. 是否是AWS负载均衡器导致的错误？

谢谢。

Answer 1

您需要向客户端添加 SSL 调试标志 - 它会显示错误的性质。 TLS 握手超时通常是由于 cipher/protocol 不匹配。

找出 Gatling 服务器使用的特定 TLS 协议和密码集，并确保您的 ELB HTTPS 侦听器使用正确的密码和协议

来自SSL Negotiation Configurations for Classic Load Balancers

Elastic Load Balancing uses a Secure Socket Layer (SSL) negotiation configuration, known as a security policy, to negotiate SSL connections between a client and the load balancer. A security policy is a combination of SSL protocols, SSL ciphers, and the Server Order Preference option. For more information about configuring an SSL connection for your load balancer, see Listeners for Your Classic Load Balancer.

尝试允许所有 ciphers/protocols 在那里。

Answer 2

所以问题似乎是因为 Gatling 握手的时间比每秒创建用户的时间长。通过减少创建的用户数量和增加 RPS 数量解决了这个问题。