Handling large web based processes

Question

I am working on a new function for a ASP.NET MVC website. The execution time is quite long at present so I am considering options.

The function takes an excel spreadsheet, uploads it to the web server. It then needs to select all of the rows and using Entity Framework insert the rows in to a database. Each row matches the required entity model. Currently at only 50000 rows, this process takes a while and I would assume the row count will grow in the future.

I have a few options for processing here and I am wondering if there is a better way to handle it. The two ideas I have just now are

1) Pass the work off to a service, which on completion emails the user. The obvious upside being the user doesn't need to keep that browser window open. 2) Add a progress bar and have the service pass updates back to jquery/javacript to do visual updates.

I will attempt to reduce the time, possibly moving the queries away from relying on Entity Framework. Sometimes stored procedures are a lot faster than Linq To Entities but with that aside, the process may still take more than a few seconds, which I don't really want to burden the user with.

Can anyone think of other/better ways to handle long running processes on a web application? Are there any best practice schools of thought on handling these situations?

Answer 1

Doing the background service or task is correct tactic here -- web servers really are meant to serve brief requests not long running tasks. Best to keep those off the server. You also get the added advantage of making things like bulk processing easier to achieve as it is sitting there waiting to do it's thing.

If it needs to be synchronous some sort of progress bar is in order. Another option would be a simple status panel and notification options, especially if things start taking longer once you have real traffic.

Answer 2

You definitely need to go async at some point, however it's quite complex and I'd avoid doing it until you really have the problem.

There are a few different approaches but your webserver should do as little as possible. The simplest way to handle this is to let it handle the upload and put the file in a folder.

There are different approaches here but another worker process will need to take the file and process it (btw, entity framework might not be your best option for this kind of heavy lifting). To spin off the other process you can typically do one of these things

• As you mentioned, you can invoke a separate service asynchronously.
• Have a scheduled service scour the destination directory looking for new files. This is good because this can be run on a completely different server from the web server if needs be, however for the same reason it's very hard, to give real time progress reports to the user. Also, you induce a latency (e.g. if you scan the folder every 5 minutes, the user might have to wait for that long at least).
• Have a the response thread spin off a background thread. Pro, it's fairly easy to get progress and push it to the browser, but con, you are using the web server to do non-web stuff, unless you are careful this won't scale as well as you would imagine.
• Post a message to a message queue that dispatches it to the background worker. This makes it possible to have 2 way communication, but it's probably the most complex solution of the three (because it has many moving parts).

I would generally advise you to use the simplest possible solution that would work and only use a more complex one if you are forced by circumstance. These kind of things tend to become devilishly complex and hard-to-debug really quickly.