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?

  • 3) Don't use an excel spreadsheet to upload data. Seriously though, who's idea was that? That just screams disaster.. – Neil Jul 15 '13 at 10:36
  • Unfortunately that is forced upon me. I am using LINQ to Excel to parse it but it takes a bit too long. Considering requesting people save to csv before import, that way I can bulk insert to SQL. – James Jul 15 '13 at 10:44
  • @James or you can do the conversion yourself. – Simon Bergot Jul 15 '13 at 11:43
  • yes, very true. My BULK INSERT thought wont work as I am using a remote SQL Server. I do not want to create a dependency on a shared folder for the file to be made available to the server. – James Jul 15 '13 at 12:20
  • I think trying to analyze an excel spreadsheet yourself is delirious and I think you could do better than that. You should explain to your client that this cannot be done, and that you require a different format. There are many ETLs which can read from an Excel spreadsheet and produce an XML you can use. However without that, trying to insert lines into the database with an Excel spreadsheet is a bit like trying to extract text from an image. – Neil Jul 15 '13 at 12:47

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.

  • I attempted to pass the file off to the SQL server and do a BULK INSERT but the file was too unreliable and it wont be very robust. I settled on the idea of passing it off to a WCF service which will do the processing. – James Jul 16 '13 at 12:23

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.