3

This program is used for taking data that has been imported and exported it line by line to normalized tables. It can take hours sometimes.

How it works is

  1. Uses presses button to begin processing
  2. A call is made from jquery to a method on the MVC controller.
  3. That controller calls a DLL which then begins the long processing

Only one person uses this program at a time.

We are worried about it tying up a ASP.NET IIS thread. Would this be more efficient if instead of the web site running the code we could make a scheduled task that runs a EXE every 30 minutes to check and process the code..

EDIT 1: After talking to a coworker the work around we will do for now is simply remove the button from the web site that processes and instead refactor that processing into a scheduled task that runs every 5 minutes ... if there are any comments about this let me know.

The question is really about the differences between the web site running code vs. a completely separate EXE...IIS threads vs. processes... Does it help any ?

punkouter
  • 5,170
  • 15
  • 71
  • 116
  • If it can be scheduled, do so. If the process needs a user to tell it to start, do that instead. As for long-running processes - you could spawn a thread within your web site which (AFAIK) won't be tying up IIS worker threads. – Yuck Dec 20 '13 at 17:16
  • How do release that IIS thread immediately and yet continue processing the code? Do I refactor my code into a .exe and use process.start to kick of that .exe when the user presses a button ? – punkouter Dec 20 '13 at 17:26
  • You'd call `Thread.Start()`, but Gary Walker brings up a good point about that thread being dependent upon its parent process - which may not always be around. – Yuck Dec 20 '13 at 17:31
  • @punkouter, I see that you are running the process every 5 minutes. If you want to lower the processing latency (those extra 5 minutes), you can use message queues for this task. Consider using [HangFire](http://hangfire.io) (easy and transparent) or [NServiceBus](http://particular.net/nservicebus) (complex, but mature) to implement fire-and-forget invocations from ASP.NET in a reliable way. – odinserj Jun 10 '14 at 17:15

2 Answers2

2

If the processing takes hours, it should definitely be in a separate process, not just a separate thread. You complicate thread locking and management, garbage collection and other things by dropping this into a separate process. For example, if your web server needs to be rebooted, your separate process can continue running without being affected. With a little work, you could even spin up this process on a separate server if you want (of course you would need to change the process start mechanism to do this)

Gary Walker
  • 8,831
  • 3
  • 19
  • 41
  • so what is the easiest way to refactor the current code to use a 'separate process'.. Is this a job for the await/async keyword? – punkouter Dec 20 '13 at 17:28
  • No, a seperate process is not wait/async. See http://stackoverflow.com/questions/181719/how-to-start-a-process-from-c" for an example – Gary Walker Dec 20 '13 at 17:36
1

When the task can run for hours having it block an ASP.Net thread is definitely the wrong thing to do. A web call should complete in a reasonable amount of time (seconds ideally, minutes at worst). Tasks which take considerably longer than that can be initiated from a web request but definitely shouldn't block the entire execution.

I think there are a couple of possible paths forward

  1. If this is a task that does need to be executed on a semi-regular basis then factor it into an EXE and schedule the task to run at the correct interval
  2. If this task should run on demand then factor it out into an EXE and have the web request kick off the EXE but not wait for its completion
  3. Another possibility is to factor it out into a long running server process. Then use remoting or WCF to communicate between asp.net and the process
JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • if only one person uses this web application and runs the processes one after another.. how much does it hurt the rest of IIS? I mean the user is just using ONE of many IIS threads right ? – punkouter Dec 20 '13 at 17:24
  • @punkouter all in all it probably doesn't hurt IIS that much. However it's still not using ASP.Net in the way it was intended and I wouldn't be surprised if it caused some corner case issues that aren't immediately obvious – JaredPar Dec 20 '13 at 17:26
  • I know its not the best but I am hoping it is passable since only one person using the web app at a time and waits for the process to finish before starting another one.. It does use a IIS thread and holds onto it.. but it is just ONE thread being held onto (how many thread does iis have?) So I am wondering if its really not a big deal in my case – punkouter Dec 20 '13 at 17:31
  • @punkouter if you're looking for me to say "yeah this is OK" it's probably not going to happen :) This is using asp.net incorrectly and it's likely this will eventually cause you some pain. For me that would be enough to try and get a better solution. – JaredPar Dec 20 '13 at 17:36
  • if I use process.start in the controller would it run async and retun control immediately back to IIS (I mean free up that IIS thread? ) – punkouter Dec 20 '13 at 17:53