Batch processing in PHP
What do you do when you have a feature in your Web application that takes longer than a second or two to finish? You need some type of offline processing solution. Check out several methods for offline servicing of long-running jobs in your PHP application.
1. Sharing data between front and back end systems via database.
2. Sharing processes between front and back end systems by storing code in the database and executing it on the back end.
3. Using files instead of databases for interprocess communication.
For example, I log in to the Web application and ask it to send all the people registered in the system a message telling them about a great new feature. This action has to be done as a batch because there are 10,000 people on the system. Such a task will take PHP a while to complete, so it must be done by a job outside the browser.
Run a cron script
Here is a simple cron configuration to run a PHP script once a day at 11 p.m.:
0 23 * * * jack /usr/bin/php /users/home/jack/myscript.php
The first five fields define the times when the script should be launched. After that comes the name of the user that should be used to run the script. The rest of the line is the command line to execute. The time fields are minute, hour, day of the month, month, and the day of the week. Here are a few more examples.
The mail queue
The first version is a dedicated mail queuing system. In this model, there’s a table in the database with a list of e-mail messages that should be sent out to various people. The Web interface uses the mailouts class to add an e-mail to the queue. The e-mail processor uses the mailouts class to retrieve the pending e-mail, then uses it again to delete the pending messages from the queue.
Something more generic
Having a solution dedicated simply to e-mail send-outs is fine, but what about something more generic? Something that lets me send e-mail or generate reports or do other time-expensive processing without having to wait in my browser.
To do that, I can take advantage of the fact that PHP is an interpreted language by storing PHP code in a queue in the database, then executing it later. Doing so requires two tables, as shown in Listing 5.
Listing 5. generic.sql
DROP TABLE IF EXISTS processing_items;
CREATE TABLE processing_items (
id MEDIUMINT NOT NULL AUTO_INCREMENT,
function TEXT NOT NULL,
PRIMARY KEY ( id )
);
DROP TABLE IF EXISTS processing_args;
CREATE TABLE processing_args (
id MEDIUMINT NOT NULL AUTO_INCREMENT,
item_id MEDIUMINT NOT NULL,
key_name TEXT NOT NULL,
value TEXT NOT NULL,
PRIMARY KEY ( id )
);
The first table, processing_items, holds the functions to be called by the job processor. The second table, processing_args, contains the arguments to send to the function as a hash table using key/value pairs.
These two tables are, like the mailouts table, wrapped by a PHP class, this time called ProcessingItems.
Dumping the database
To finish the code examples, I show a slightly different angle, which is to use files in a directory to store the batch jobs instead of using the database. I offer this idea here not so much in the mindset of “Do it this way, rather than in a database,” but as a design alternative you can use — or not use, as you choose.
