-
Notifications
You must be signed in to change notification settings - Fork 26
Webpa XMiDT Timeouts
Note: These values might be on the extreme upper bound end. As we see the cluster behave in production, we can make more data-driven decisions on the values later.
"...time from when the connection is accepted to when the request body is fully read"
This should be set on a per-machine basis (due to the fact that machines communicate with each other and the need to synchronize such communication)
-
Anteros:
150s -
Tr1d1um: Anteros request timeout +
5s -
Scytale: Tr1d1um request timeout +
5s -
Petasos: Scytale request timeout +
5s -
Talaria: Petasos request timeout +
5s(if even applicable) -
Caduceus: Caduceus caller request +
5s
Note: Why the 5s increments? From observation, better behavior is seen if client requests time out before servers do. That is, requests coming from Anteros to Tr1d1um should time out first before the Tr1d1um server does to avoid client-server connections being cut off. 5s might be enough to include time spent through glitchy/slow networks
"... time from the end of the request header read to the end of the response write (a.k.a. the lifetime of the ServeHTTP)"
I believe this should follow the exact pattern laid out for http.Server.ReadTimeout
This should be done on a per-machine-type basis. Whereas the client is implementing timeouts using context or http.Client.Timeout, it should be upper-bounded by the timeout values set by the server these clients call.
Source: https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/