< Browse > Home / Software Development / Blog article: Offloading Heavy Processing In Dot Net Web Applications

| RSS

Offloading Heavy Processing In Dot Net Web Applications

February 27th, 2009 | No Comments | Posted in Software Development

Executing heavy long running processing jobs within the application page lifecycle hardly ever desirable from a user experience point of view.

After all no user likes to click a button and wait 5 minutes for a response.

So how can we handle this?

This is where IIS application pools comes in to save the day. Lets take a step back and see whats going on behind the scenes. The traditional web server model is based on a single thread per page lifecycle with no possibility for processes to execute beyond the page lifecycle. IIS on the other hand extends this with through its application pools. In essense all IIS web applications execute within a long lived process model. The life of each web applications process is determined by when the application pools are recycled.

What does this mean?

What this boils down to is the following:

  1. If we set the value of a static property, this value will be preserved until the application pool recycles.
  2. If we start a new thread, this thread will execute either until it completes or until the application pool is recycled.

Herein lies our opportunity. Work items can be queued via threadsafe static properties. These queued work items can be processed in the background by threads which are independent of application page threads.

One thing to keep in mind is that in the application pool properties under the health tab the shutdown time must be set high enough to allow any background threads to gracefully shutdown. It is also a good idea to use the application startup and shutdown events to fine tune startup and shutdown of background processing threads. The application startup and shutdown events can be bound to by using the global.asax file.

The system design in a nutshell:

use the global.asax application startup event to initialize your background processing threads. Don’t forget to add a watchdog thread to restart processing threads should they unexpectedly terminate.

use the global.asax application shutdown event to terminate your watchdog thread, halt new items from being added to the processing queue and gracefully shutdown background processing threads.

Create a static work item queue class with a private static list of items to be processed and public insert and remove methods to push and pop the queue. The public insert and remove methods have to be thread safe using either synclocks, reader writer locks or another thread syncronization locking construct.

On application start. create a 1 or more background processor threads to process items from the work queue.

The watchdog mechanism can be implemented as either a separate thread or it can be implemented as a check which runs each time the above insert work item method is called.

Monitoring the work queue for user feedback:

If this functionality is required then the work item queue can be implemented as a dictionary of <key,workitem> pairs. an additional static method can be provided within the work queue which when provided with a key will return the status of the work item.

Leave a Reply 12251 views, 2 so far today |

Comments are closed.