Reply to: Avoiding client timeouts in a hellishly slow web app (and server timeouts)

[Sysman]

It shouldn't do, as XHR initiates a new request/response cycle each time the client polls - this would mean that the connection had become active again.

You could always disable keep-alive by sending Connection: close with the response.

However, the fundamental fix is to avoid anything that sends an HTTP request in the expectation of having to wait many minutes for the associated response. Quite apart from the client dropping the connection, there are potentially proxies and routers and what have you that could also decide that the connection must have died and drop the matter, and you can't do anything about them.

Good point.

What happens if the user simply closes the browser? I instinctively don't like the idea of polling to see if a lengthy report is finished. Why not simply send an email. If that's unacceptable you could stick in a report queue of some kind which can be queried, but that sounds like a project on its own.

[NickFitz]

Thanks Nick, that's exactly how I would have done it (and have done with similar requirements in the past).

But the point is, won't the step I've left above in the quote of your reply suffer exactly the same problem with keep-alive (AKA client) timeouts? I don't think Ajax requests reset the keep-alive timer do they, and that's what is giving me grief.

It shouldn't do, as XHR initiates a new request/response cycle each time the client polls - this would mean that the connection had become active again.

You could always disable keep-alive by sending Connection: close with the response.

However, the fundamental fix is to avoid anything that sends an HTTP request in the expectation of having to wait many minutes for the associated response. Quite apart from the client dropping the connection, there are potentially proxies and routers and what have you that could also decide that the connection must have died and drop the matter, and you can't do anything about them.

[eek]

Thanks Nick, that's exactly how I would have done it (and have done with similar requirements in the past).

But the point is, won't the step I've left above in the quote of your reply suffer exactly the same problem with keep-alive (AKA client) timeouts? I don't think Ajax requests reset the keep-alive timer do they, and that's what is giving me grief.

I think the problem is that you really need to separate the report from the web server into its own routine. You then need to create a means of starting the report script and add something at the end of the report to provide feedback announcing that the report is available at x..

I think rewriting some of the code is unavoidable.

[yorkshireman]

Is it an option to run the number crunching report periodically on cron and output the results to a static html page?

The user then perceives instant response.

This prevents the user getting bored and refreshing the page repeatedly and stressing the server (as they might!). Albeit that the results are not real-time.

[OwlHoot]

::
[*]Client periodically asks the server if the task associated with the unique token has completed;

::

Thanks Nick, that's exactly how I would have done it (and have done with similar requirements in the past).

But the point is, won't the step I've left above in the quote of your reply suffer exactly the same problem with keep-alive (AKA client) timeouts? I don't think Ajax requests reset the keep-alive timer do they, and that's what is giving me grief.

[NickFitz]

Yup, if the report is taking that long to generate then trying to increase the amount of time the client waits is all wrong. Also, you're going to run into huge scalability problems if the server's HTTP request handler threads are getting tied up with such long-running tasks, which will lead to 503 Service Unavailable errors being returned to other users once a few requests are in process.

1. Client makes request;
2. Server kicks off new process, identified by a unique token, to do the long-winded work in the background;
3. Server returns token to client (probably as 202 Accepted), leaving that server thread free to handle another request;
4. Client periodically asks the server if the task associated with the unique token has completed;
5. Server checks to see if long-winded process has completed and lets the browser know what the current status is;
6. If the response to the preceding step indicates that the report is ready, redirect the browser to it, otherwise let the user know what's going on and poll again a little while later.

This approach has the advantage that, if the processing required to create the reports when under load is still affecting the ability of the HTTP server to do its job, that processing can easily be handed off to another machine, or machines if you're in an environment like EC2 where it's easy to just spin up a few more servers during busy periods then shut them down again when things quieten down.

[DimPrawn]

make an async request and poll for a result file ?

WHS.

The design is all wrong.

Make post to kick off an async process to generate the results. Poll for results ready (yes/no), results are ready, download completed results.

Or, async submit work. Background process generates results and emails them.

Timeout issue is masking a poor design/architecture.

[FiveTimes]

make an async request and poll for a result file ?

[Sysman]

This s a problem I had 20 years ago with dumb terminals. Of course I could fix the timeout, but the real problem was that the user couldn't do anything else on their terminal until the job finished. My solution was to submit the report job to batch and send the user a message when it completed.

A similar approach seems appropriate here. In modern terms that could translate to sending the user an email either with the report attached or with a URL pointing to it.

This also deals with a PC/browser/network crash; the user won't be submitting the (presumably resource intensive) job multiple times simply because something went wrong at their end.

[Spacecadet]

Store the results of the report elsewhere and then the page that the user is on simply polls the server to see if the results are available yet. When they do become available the user is informed and clicks a further link to retrieve the results.

You might want to do something so that if the server isn't getting "is it finished yet?" requests then it will cancel the job automatically.

[dang65]

I don't know what the format of this report is, but it sounds like it might be a very large dataset. If it is, then the traditional method is to paginate the results so that the request is much smaller each time a call is made to the server. But that seems too obvious to have not been considered previously... although you do mention that the report generating code is out of your control.

[OwlHoot]

well ajax is simply javascript so you could have a static web page with a javascript routine called every x seconds to check the status of the request. ..

Sure, but what is to stop the initial Ajax request (to run the report) from timing out in the same way as a POST with no reply within the time?

Or will the periodic checks thereafter reset the client timeout timer each time?

I guess the checks would have to be actual HTTP requests themselves, and not just Javascript "is this flag set" checks, although there would be no way they could _actually_ check anything useful. But dummy requests, even to http : dontcare . com or something, would be fine as long as they reset the keep-alive client timer.

[Durbs]

Then once the report is generated and the script returns success you redirect the page to the report.

But looking what he's posted above, it wont return a report, the server will return an execution timeout to the browser whether its ajax or not. Just sounds like the report is exceeding the default timeout period e.g 180 secs and is therefore returning an error. Increase the timeout and the browser will wait as long as you like.

[OwlHoot]

What are you using server-side to generate the report? Java, .NET, PHP ????

Its there that you want to set the execution timeout.

It's a _client_ timeout, something that occurs in the browser if it doesn't get a server response within a certain time.

edit: Durbs, re your reply following this post, it _isn't_ the server returning the timeout (although I realize Apache also has a request timeout, which I'll worry about later). It's wretched _Firefox_ complaining it hasn't heard anything back within the "keep-alive" time. So in short you're barking up the wrong tree. But thanks anyway - I may have problems with server timeouts and proxy timeouts later!

[eek]

well ajax is simply javascript so you could have a static web page with a javascript routine called every x seconds to check the status of the request.

Then once the report is generated and the script returns success you redirect the page to the report.

I do have examples but don't have one on the box I'm typing this on (the joys of locked down machines and stupid security rules).