0

I'm trying to wrap my head around network timeouts and how they should be set for each hop of a given request. For simplicity, I'm not looking at a breakdown of connect vs. read vs. write timeouts and will assume "timeout" means "max allowed total time from first packet received to last packet sent (or vice-versa for the client). Say I have the following hops in my request flow:

(client) --> (AWS ALB) --> (nginx) --> (server)

…and let's assume that my server is set up to timeout after 10 seconds.

My question: what would be a valid set of timeouts for every hop? Would it be

// A
(client, 13s) --> (AWS ALB, 12s) --> (nginx, 11s) --> (server, 10s)

or

// B
(client, 7s) --> (AWS ALB, 8s) --> (nginx, 9s) --> (server, 10s)

or (C) something else?

Obviously, I'm also interested in the logic behind your suggestions.

caccialdo
  • 1

1 Answers1

1

If you're looking at hard timeouts (you don't state the purpose), each processing stage has less time than the previous one. So basically, A is the right approach.

However, the client-to-AWSALB path is beyond your control and may be comparatively lengthy/slow. One second per steps seems very generous, so no problem there. But if you decrease that to 50 or perhaps 100 ms per step, the first step will need some more allocation.

Zac67
  • 10,320
  • 2
  • 12
  • 32
  • Thanks Zac - this is also what feels the most intuitive to me. However, one thing I didn't mention in the original post is that I found [this recommendation](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#connection-idle-timeout:~:text=We%20also%20recommend,connection%20is%20closed.) in AWS docs for ALBs that seem to imply that B should be preferred. I could be misunderstanding their sentence though, or it could be a recommendation for a different scenario than hard timeouts. – caccialdo Dec 16 '22 at 11:42