[RESOLVED] A Good Timeout 5, 10, 15, 30 seconds?

bike5

What is your opinion on a good timeout for an ajax call. I don't want to too fast in-case someone using dial-up takes say 5 seconds to load a request but don't want it too long because of the situation below:

I have a quiz that loads questions 1 by 1 via ajax and sometimes for whatever reason a customer says the test just stops loading a new question and I think its just a network problem where the ajax return never got returned. I am writing it so if after X second of no reply it automatically re-queries the server (if it it was just a network hiccup it will hopefully load the second or third time without anyone calling us saying our system is broken). This happens to a few people out of thousands so I am pretty sure its just a random network issues where the ajax request just never gets returned. If I put the timeout too long like 30 seconds people will probably give up half way through waiting and call support or leave the page.

I guess I would rather side on longer then shorter because I don't want "valid" slow connections hitting an infinite loop of re-ques because there slow connection keeps getting timeouts. Oh, the data the ajax is returning is pretty small, around say 200 characters average (a question and some answers).

Thanks for your thoughts and input.

bradgrafelman

bike5;10998563 wrote:
I don't want to too fast in-case someone using dial-up takes say 5 seconds to load a request

Well wait a minute - what type of timeout are we talking about? Are we talking about a connection timeout, e.g. your AJAX code sends an HTTP request but doesn't receive a reply of any sort after X seconds? Or are we talking about a total response timeout, e.g. even if server responds to the HTTP request but transmits the body of the response too slowly (e.g. after 15 seconds, you're still getting bytes coming in as part of the original response)?

bike5;10998563 wrote:
I have a quiz that loads questions 1 by 1 via ajax

Why not store all of the questions in a JSON-encoded array-like structure of some sort and just send them all in one go? That would cut down on the overhead of multiple HTTP requests/responses quite a bit, and would probably help improve the reliability/stability issues you're seeing (rather than needing 20/20 requests to all work, you only need a single successful attempt).

bike5;10998563 wrote:
I guess I would rather side on longer then shorter because I don't want "valid" slow connections hitting an infinite loop of re-ques because there slow connection keeps getting timeouts.

In that case, you could get a bit fancy and come up with a dynamic timeout scheme.

For example, set an array of timeout values in increasing magnitude (example: 2 secs, 3 secs, 5 secs, 10 secs, 15 secs, 20 secs) and start with the smallest timeout value. When you hit a timeout condition, increment a "next timeout value" pointer to the next highest timeout value.

You could then expand it even further to start decrementing the timeout pointer once you start getting successful responses with no timeouts.

bike5

Well wait a minute - what type of timeout are we talking about? Are we talking about a connection timeout, e.g. your AJAX code sends an HTTP request but doesn't receive a reply of any sort after X seconds? Or are we talking about a total response timeout, e.g. even if server responds to the HTTP request but transmits the body of the response too slowly (e.g. after 15 seconds, you're still getting bytes coming in as part of the original response)?

I am not sure what is happening to users, I can't duplicate the problem its just a guess but I would say the server is probably not returning anything rather then trickled in data but again just a guess based on the fact it works fine and quick for someone then they say all the sudden a question fails to load.

Why not store all of the questions in a JSON-encoded array-like structure of some sort and just send them all in one go? That would cut down on the overhead of multiple HTTP requests/responses quite a bit, and would probably help improve the reliability/stability issues you're seeing (rather than needing 20/20 requests to all work, you only need a single successful attempt).

That's a good idea but something I can't do at this time due to time restrictions and the way the system is setup.

In that case, you could get a bit fancy and come up with a dynamic timeout scheme.

For example, set an array of timeout values in increasing magnitude (example: 2 secs, 3 secs, 5 secs, 10 secs, 15 secs, 20 secs) and start with the smallest timeout value. When you hit a timeout condition, increment a "next timeout value" pointer to the next highest timeout value.

You could then expand it even further to start decrementing the timeout pointer once you start getting successful responses with no timeouts.

I like this idea, never thought of doing anything like this. I will probably work on doing something like the dynamic timeout.

Thanks for the input.

johanafm

bike5;10998571 wrote:
I am not sure what is happening to users

Well, why don't you try to find out? If you read about the event onreadystatechange you'll find out how to start narrowing down where things go wrong. Since you can't duplicate the error, it might be an idea to give some information to the end user who gets the error and ask them to provide support with that information.

bike5;10998571 wrote:
That's a good idea but something I can't do at this time due to time restrictions and the way the system is setup.

Doing that should take less time than anything else regarding the problem you have. All you need to do is perform the first request, but instead of replying with one question (possibly using SQL code such as WHERE query_id=1) you get all questions (ditch the where clause).

Once you have a response object containing all questions, you turn them into an array. Every time the user answers a question, you step to the next array element, rather than sending a new XHR.

Time to fix ought to be about 20 minutes, at least unless the selection of following questions depend on previous answers, in which case it would of course take more time.