Offloading slow batch tasks to an external process is a common method of improving website responsiveness. One great way to initiate such background tasks in PHP is to use Oracle Streams Advanced Queuing in a producer-consumer message passing fashion. [...] The following example simulates an application user registration system where the PHP application queues each new user's street address. An external system monitoring the queue can then fetch and process that address. In real life the external system might initiate a snail-mail welcome letter, or do further, slower automated validation on the address.

He includes the SQL needed to create the database and configure the queue system as well as start it up and get it ready for requests. He shows how to push an address into the queue for processing and how to get the results once it has completed in both the SQL and from the oci_* functions in PHP.

When designing client libraries to send data to our API, one of our top priorities is to make sure that none of our code affects the performance of your core application. That is tricky when you have a single-threaded, "shared-nothing" language like PHP. [...] Ideally, we like to keep the setup process minimal and address a wide variety of use cases. As long as it runs with PHP (and possibly a common script or two), you should be ready to dive right in. We ended up experimenting with three main approaches to make requests in PHP. Here's what we learned.

Their three suggestions don't involve external dependencies (like a queue server) and can operate pretty quickly:

• Opening a socket and closing it before waiting for a response
• Write to a log file (a pseudo-queue)
• Fork a curl process (through something like exec)

They each have small code examples included with them and explanations as to their plusses and minuses. For their needs, the "forked curl" solution worked out the best, but check out the other options too - you might have different needs.

• Part one introduces the idea behind working with a background queue, the general workflow a process would follow and some of the benefits/drawbacks of using them.
• In part two he gets more into the actual queue system and discusses the concept of a "job".
• The third part gets more into the implementation and helps you get the PHP-Resque, predis extension and the process control extension installed.

The fourth part of the series (pending) will get into the actual code to implement this system you've job installed.

RabbitMQ is open-source message brokering software written in Erlang. The MQ in its name refers to a standard known as Advanced Message Queuing Protocol. For our purposes, and most others, it acts as a middleman between producer (sending) and consumer (receiving) programs - it simply accepts and forwards messages. [...] Both producers and consumers can be written in any language that has an available RabbitMQ or AMQP client library. In this article, I'll demo a producer program written in PHP and a consuming program in Python.

He walks you through the installation for both RabbitMQ itself and the PHP (php-amqlib) and Python (pika) tools to use for the interfaces. There's some details on how the queuing system works and the code for the sample clients is included as well as commands to use the two clients to send/receive messages.

I have a webpage form that requires a date and time to be submitted. When it's submitted I need the back-end to run a script at the time and date specified. Have you ever needed to do something like this?

Some recommendations already posted include:

• The UNIX "at" command
• Setting up a queue system to manage the processes (using something similar to Gearman
• Setting up a cron job to handle the periodic execution of the script.

I have looked at the state of different messaging backends recently and i ran a little benchmark to see what is the rough comparison of message publishing throughput. Results that i got are quite surprising. What i wanted to achieve is some sort of reassurance before choosing a messaging bus for my PHP project.

Running both the PHP and the messaging test scripts on the same server, he pulled from a few different backend systems - RabbitMQ, MySQL, MongoDb, Memcached and ActiveMQ. The results were interesting, showing an interesting result in the time it took to execute versus the number of messages per second pushed in.

You now have a queuing system that works and generates pdfs which are sent to users as per RabbitMQ and PHP Part 1 of this article. A week later after launching the queuing system you get one or two queries from users who claim to have made a request to get the pdf report but it never arrived. Okay, what could have happened ? well you go through the application log files and as suspected - An Exception was thrown by one your classes as the consumer was trying to create the pdf and that is why it was never sent. Now this compromises the queuing system Totally, But wait there is a way to help prevent such.

He shows how to make your queues "durable", meaning they'll survive a broker restart and they require a response from the consumer before being removed. He shows how (via the php-ampq functionality) to add the "AMPQ_DURABLE" flag to the queue definition. He also includes some code showing how to send back the acknowledgement so the entry can be removed from the queue. He also includes an update to the code that calls "publish" to make the messages persistent too.

Web applications usually follow a synchronous communication model. However, non-interactive and long-running tasks (such as report generation) are better suited for asynchronous execution. One way to off-load tasks to run at a later time, or even on a different server, is use the Job Queue module available as a part of Zend Server 5 (though not as part of the Community Edition). Job Queue allows job scheduling based on time, priority, and even dependencies

In his two examples, he shows the code involved to create a new Queue object and define a HttpJob in it. The first just calls a "sample.php" script that's exposed as a part of your external-facing site and shows how you can get the current status of the job. The more advanced example shows a call to a "report.php" script with a set of options defining things like "type", "length" and "priority". He also points out some other options that can do similar things like Gearman, NodeJs and RabbitMQ.

Sometimes there are situations when you want to parallel process things. Other times you might have a list of tasks to accomplish, and you don't want to make the user wait after pressing a button. This is where "Workers" can come in. They are independent scripts that run along side of your application, performing tasks, or "jobs."

Solo is a very basic Perl script that ensures only one process of a type is running at once. Using this and a PHP library called predis, he shows how to set up workers and add items to your processing queue. The workers themselves run on a cron job and connect to the queue server to see what they need to do. He also throws in some "bells and whistles" - extras that can enhance your worker system: queue monitoring, version numbering and killing workers based on a hash value.

His code examples are posted on his github account and a screencast is included in the post to show the system in action.

The majority of [cell phone] users have opted to receive an email, but a significant number are now opting to receive the notifications via SMS. Here's the problem: How do you send a message via two different channels to both groups of users? The logical approach would be to split the users into 2 groups, email recipients and SMS recipients, which would involve running 2 different queries and sending the codeword to each group separately. Using the Command Pattern, which I will introduce you to in this article, you can send the message to both groups of users in a single process.

He uses the message queue he mentioned as an example - showing how you can can queue up different kinds of objects (actions) based on a common interface into the same process. He creates a "DailyAlertEmail" and "DailyAlertSMS" classes, both with a "send" method. The settings for these are then pulled from a database and the "execute" method on the "MessageQueue" class is called to loop through them, calling "send" to do that work.