What happens behind the scenes
Hi All,
I am Andrew the Development Manager here at LCN.
Currently we are working on some big changes to our hosting system. As well as improving reliability and performance we are overhauling the way hostings are set up and reported on. Whenever a customer purchases a hosting we automatically configure that hosting account as soon as possible. However quick we set up the hosting though we don’t want to keep you waiting while its done. We also want to free up our web server process so it can continue serving other users. The best way to do this is to create a background job. There are many systems for creating background jobs in most programming languages.
Why not just use a cron job
Most people who have ever worked with Linux will be familiar with the cron for scheduling jobs to run at a regular interval. One of the simplest ways of making jobs run in the background it to create a queue in the database and have a cron job that runs runs through the queue every few minutes. There are a few problems with this though:
- If there is a large backlog a second cron job may start before the first one is finished
- Tasks may be sitting in the queue for a while waiting for the next interval
- With a large application there may be a considerable start up cost
How a message queue works
With a message queue there is one or more persistent queue listeners waiting for jobs. Each queue listener ‘subscribes’ to a queue. When the web process wants to offload a task that will take some time to process then it writes a message to the appropriate queue and the queue listener will process the jobs in the order that they are enquired. There are many different tools for doing this, one of the best known of these for Ruby is Starling from the people who brought you Twitter. Another popular message queuing system is ActiveMQ from Apache. ActiveMQ uses a the STOMP protocol so it can be used in any language. ActiveMQ has a central message broker (written in java) which hosts the queues. Another advantage of having a central message broker is it can be used for asynchronous communication between applications.
Synchronous verses Asynchronous communication
Web requests (HTTP) are synchronous requests, your browser sends a request to the web server and it immediately replies with a response. This makes perfect sense for web browsing but it is not the only way to communicate. It also has some disadvantages like if the web server is busy your request fails.
One of the most popular ways of communicating with separate systems in Ruby applications is using HTTP REST to exchange xml documents. By looking at what requests need to be synchronous (e.g. querying disk quota in your account) these can be done via REST to give an immediate response. Slightly longer operations (e.g. upgrading a hosting) can be done using message queues. By separating the calls that need to be done immediately and calls that can be done behind the scenes we can then produce a much more responsive my account section of our website.
I hope you found this information useful. Please feel free to leave comments below.
