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

[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.

[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.

[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.

[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.

[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.

[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.

[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.