puma在ALB转发IT

Question

I在Rails应用程序上有一个常规的Ruby，其PUMA服务器运行了配置

-w 1 -t 1:1

（即一个工人和一个线程）。这部署在AWS ALB面前的EC2实例上。如下所示，相当标准的设置。

我们在特定时间开始观察某些请求的缓慢。检查ALB日志时，我发现了几个大于8-10秒的请求。当我查找Rails日志中的相同请求（基于请求方法，路径，客户端IP和请求时间范围）时，请求显示为已在几毫秒中处理过。

奇数是，与ALB日志中收到的请求时间戳相比，轨道日志本身的

Target Processing Time

线的时间戳为8-10秒。根据ALB日志，它花费了大约1毫秒来将请求转发到目标。因此，请求在该持续时间内没有卡在ALB上。

AWSALB的连接超时为10s（即目标应在10s内接受TCP连接）。如果没有，请求不被视为转发和标记为

Started

。由于这些请求并非如此，因此EC2机器已接受该限制内的连接。

ref：在此处查看

Error

https：//docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html#access-log-entry-syntax

因此，看来该请求是在8-10秒的OS级别或PUMA主级排队的，此后将其交给工人处理请求。

问题：

我的要求在哪里卡住？我怎么能找到它？

我如何找出导致这种延迟的原因？

我可以监视一个指标，以提醒您有关此类情况的警报？

您正在运行多少puma服务器？
如果您有一台运行的服务器，一次只能处理一个请求。
3. 如果大量请求同时触及了服务器，他们将坐在OS的积压中，直到PUMA可以处理它们。