0

We have a somewhat special use case where we are allowing a user to still make a rather slow/large backend http GET request in a synchronous manner (until we implement async systems). The website would likely hang for a few seconds. Are there any potential issues we should consider? Are there engineering constraints that we should keep in mind when coming up with a timeout? e.g. could there be default limits implemented with load balancers, client libraries, etc... that might be 30 seconds or so?

I think 5 seconds or less could likely handle our use case. Could that pose a problem? Let me know if any details are needed. It's possible this question is too vague and really dependent on the intricacies of each setup.

serverFaulter
  • 385
  • 2
  • 4
  • 9
  • 1
    For an interactive website I expect that your users might lose their patience well before time-outs become a technical problem. There is, as far as I know, no "standard" timeout for web requests, those will be specific to the implementation. The lowest time-out will be the limiting factor and that can be the client, their proxy server, your load balancer, your application server and anything else on the path between your client and the back-end server. – Bob May 20 '21 at 16:38
  • @bob Thanks. Yes, we would likely add an indicator on the client app. It sounds like we'll need to play it safe w/ a lower number considering there could be various timeouts that could trigger. I think we might just try for something conservative like 5 seconds, or else need to look through our stack for all the timeouts that exist. – serverFaulter May 20 '21 at 21:55

0 Answers0