19

It there any article/book that defines upper bounded design limits for WS timeouts? Do you timeout at the server or recommend the client specific timeouts too?

Is there a common best practice like "never design WS that can take longer than 60 seconds, use an asynchronous token pattern"

I am interested in knowing what you do or your opinion too.

MMind
  • 1,845
  • 2
  • 17
  • 26

4 Answers4

17

This stuff about 30+ second timeouts is ridiculous advice, IMO. Your timeouts should be about 3 seconds. Yes. Three. The number after two and before four. If you're building an application based on a SOA, then DEFINITELY 3 seconds, or less.

Think about it... the user of your app expects a TOTAL response time of about five seconds or less (preferably about three). If EACH INDIVIDUAL SERVICE CALL is taking more than a couple of* milliseconds* to return, you're hosed. Waiting 30+ seconds for ONE service to return is an eternity. The user will never wait around that long. Plus, if you know they're supposed to return in the sub-one second range, what's the point of waiting for another 30 or more seconds to signal an error condition; it's not going to magically work where when it didn't 28 seconds ago. If your application has wild swings in average response time from sub-one second to over 30 seconds, something was designed incorrectly. You might think about some caching or something.

Robert C. Barth
  • 22,687
  • 6
  • 45
  • 52
  • 10
    It can be a service between application servers, not really end user related. – MMind Nov 16 '08 at 04:01
  • 1
    Interesting, @Robert how do you come to that number: 3 seconds? – DanielV Jan 26 '17 at 09:59
  • 5
    This advice seems facetious. Of course users expect quick response, but is getting an error back in 3 seconds really better than getting a valid answer in 20 seconds? Designing for a rapid response and choosing a client timeout are not the same thing. – Nick May 17 '17 at 21:01
  • 1
    Getting a valid response in 20 seconds isn't useful because the user is already gone. See Amazon's work in this area RE: how long users wait for UI to render. – Robert C. Barth Jul 11 '17 at 18:15
  • 3
    I think we all agree that fast responses are preferred and your system should be designed to return data quickly, but I also agree with Nick's reasoning. As a user, I would be happy to receive a response better late than never. – Adam Davis Jan 11 '19 at 19:07
  • I use tor browser, and the amount of times I was sitting here, waiting for stuff to happen... If everyone built websites/clients like you, I'd see timeouts left and right and all around and internet for me would be completely unusable. And that's why I -1, simply because I really don't mind opening a new tab, going to the site and doing something completely different, but I might be biased, as most of the pages I have open are either SO or online documentation. –  Nov 23 '19 at 09:58
  • @DanielV https://stackoverflow.com/a/69293989/13903942 – Federico Baù Sep 23 '21 at 04:21
  • this is very bad advice, while it is good in theory and you should design your backend to be able to take a request, process and reply in under 1s for most transactions (uploads and large reports will no doubt take longer), all of that careful design goes out the window the second you have a user with a poor connection. I have one user on a desktop, with a 100mbit connection with low latency, but he times out at 10 seconds at times because his wireless router sucks. then you have the mobile users, who are on the edge of reception or in a carpark etc. – mike16889 Feb 06 '22 at 00:38
10

This question, and the ones linked to in answers to it, might help: Is there some industry standard for unacceptable webapp response time?

Somewhat tangential to your question (no time intervals, sorry), but I suspect useful for your work: A common approach to timeouts is to balance them with "back-off" timers.
It goes something like this: The first time a service times out, don't worry about it. The second time in a row a service times out, don't bother calling it for N seconds. The third time in a row a service times out, don't call it for N+1 seconds. Then N+2, N+3, N+5, N+8, etc, until you reach some maximum limit M.

The timeout counter is reset when you get a valid response.

I am using a Fibbonacci sequence to increase the "back-off" time period here, but of course you can use any other suitable function -- the point being, if the service you are trying keeps timing you, you "belief" in it get smaller and smaller, so you spend fewer resources trying to get to it, and knock on the door more rarely. This might help the service on the other end, which could simply be overloaded and re-requesting just makes matters worse, and it will increase your response time since you won't be waiting around for a service that is unlikely to answer.

Community
  • 1
  • 1
SquareCog
  • 19,421
  • 8
  • 49
  • 63
  • It's more common to have a geometric progression instead of a linear progression (eg. N, 2N, 4N) -- to prevent the server from being hammered. – ashes999 Jan 13 '12 at 14:38
  • 3
    It's also common to add a random amount to each retry after the first so that the service that is down doesn't get destroyed by everything retrying at the same exact time. – Robert C. Barth Apr 07 '14 at 21:00
2

Take the amount of data you are transfering via your web service an see how long the process takes.

Add 60 secs to that number and test.

If you can get it to timeout on a good connection then add 30 more seconds.

rinse and repeat.

branchgabriel
  • 4,241
  • 4
  • 34
  • 48
2

We generally take the expected response time for that web-service (as documented in our interface specification) and add 30 seconds to it.

Then we monitor the logs during UAT to see if there are any patterns (e.g. specific DB calls taking a long time) and alter as appropriate.

rbrayb
  • 46,440
  • 34
  • 114
  • 174