In any complex web application there is a need to perform operations on user request, these operations can become long running, especially when the server is under load. In order to mitigate this, a web application should leave most of the work for background processes.
Long running actions make the interface feel sluggish, and are subject to termination by the user, and as mentioned in a previous article, a slow website can harm conversion and lead to unhappy users.
Long running processes can also mount up and when under heavy load, can prevent the webserver from dealing with new requests.
When a request is received, the application should do the minimum work required for it to maintain the user interface, and should instead add any remaining work to a job/task queue.
As far as job queues go, you probably cant go wrong with Gearman1, although there are many others, such as the ruby focused Resque2, as well as the python focused Celery3 and Beanstalk4, which should be considered to see which suits you best.
The exact technology does not matter so much as the process, taking the example of a blog comment, the backend should validate the form submission and report ack to the front-end, if the submitted data is valid, a job should be added to the background job queue to process the comment, performing the database insert, Askimit or Typekit validation, and sending any notification emails.
In our comment example, a sudden spike in the rate of comment submissions will result in a larger queue and a delay in the comments arriving in the moderation list, rather than causing excess load on the database, and the user gets immediate feedback without having to wait for the various processes involved to complete.
A job queue is a great tool in the quest for responsive web applications, allowing us to perform complex processing in response to user action actions, without causing the interface to become unresponsive, and in the mean time helping to deal with any unforeseeable spikes in traffic.
© 2010-2012 Daniel Knell