If my web application takes 20 secs to complete a request, is it a bad design?

Question

I have a web application, which does some solid document processing work in the background. Once a user uploads a document for processing, it takes up to 20secs to finish processing. Right now, I try to engage the user using a progress bar that gets updated every second.

1. If a web application takes 20 seconds to do some serious backend processing, is it a bad application?
2. Have you come across web applications in which, processing takes greater than 10-15 seconds? Are there any popular websites on the internet that do the same?
3. Does it make sense to re-design this kind of time taking application to be a batch-driven application? An application that would send async messages to users after processing is complete (say, email/sms).
4. Right now, I am able to serve up to 30 users per minute or less. From an infrastructure perspective, if I have to scale this to serve in excess of 5000 users, would it make sense to scale out (buy more machines)? If yes, how do I calculate how many machines I would need? Say for instance, the application is used by 500 users during work hours (9-5).

Answer 1

In my opinion :

1. Considering serious backend processing , I would not mark it a bad application .

2. Surely there will be sites as such having intense back-end processing : Document , Image , Audio , Video , etc .

3. Where possible , surely such processor intensive tasks in my opinion should be handled in batch processing mode . Such tasks can probably be delegated to secondary machines . There could be an option for the user to opt for a job complete notification if a job took in excess to a set duration . Also you could send job complete notification to users who sign out while their jobs are still being processed .

4. Considering user scaling , it probably makes sense to scale resources . It probably would not be a easy task to calculate the resource scale requirement . You could have logs to find out number of documents processed and the durations they took on average as well as at peak usage times . Those figures combined with the current average number of concurrent users , could help you come up with rough estimates for resource scaling .

Answer 2

For requests that take a long time and cannot be sped up for technical reasons (dependence on external systems outside your control, scarcity of resources), do what facebook and youtube do: do the job in the background and provide a notification system to let the user know when the job is finished. That way the user doesn't need to wait for their request to finish (and worry what will happen if they accidentally go back or refresh the page), but they still get feedback as soon as it's done.

A well-executed feedback system can even provide a progress bar as part of the "notification". Applications on Android do this with notifications.

Answer 3

The question is a little too reliant in opinions, but anyway.

1) Depends of what the user expects. If I know I am sending a job request that is going to be heavy, maybe I will not find it too slow. If it is surfing static content, it is. In the same way, I do not expect to spend the same time downloading a picture than downloading a film.

2) Not that I know of. But again, what is your website offering to the user?

3) For 15-20 seconds I would not say that it needs redesign to support batch jobs. When it gets into the minutes maybe.

4) Impossible to know without a detailed study. It is just that you need more CPU/memory? Or maybe there are synchronization issues and having more users will cause the problem to grow exponentially? And don't forget that when you solve a bottleneck is only because something else has become the bottleneck.