SitePoint Sponsor

User Tag List

Results 1 to 2 of 2
  1. #1
    SitePoint Addict
    Join Date
    Sep 2008
    0 Post(s)
    0 Thread(s)

    Is my PHP background task / Cron idea a good way to do this?

    I want to run certain tasks in the background and not on user request (e.g. send a transactional email and then based on the response do another action).

    If I had a script which added this info to a database:

    - PHP class
    - PHP method
    - parameters to pass to that method
    - etc.

    ..and then every 5 minutes one Cron Task retrieved all the data from this database and executed those tasks (using class, method and params), is this secure?

    It sounds a great idea to me. I could just store details of any class and method (and params) and have it run later.

    If there was only one or two tasks then I suppose I could just write a specific script and execute as a Cron Task, but this gives me flexibility to run anything.

  2. #2
    SitePoint Enthusiast adear11's Avatar
    Join Date
    Oct 2003
    Richland MS
    0 Post(s)
    0 Thread(s)
    It sounds to me like what you are trying to accomplish a Message Queue system. Something along the lines of RabbitMQ or Amazon SQS.

    I've had a similar task to solve at my company. We allow users to, among other things, generate PDFs on demand to track their progress through our course. When they request a PDF, the web server sends a message to Amazon SQS. Then, on a "backend" server, I have an Upstart job that is monitoring the Amazon SQS. When it sees a new message, it reads it and does whatever it asks.

    My job that monitors the Message Queue uses what I suppose you would call the Command Pattern. Each message consists of a json encoded message that is:

    Code PHP:
     $message = array(
        "command" => "PDFCompletionCertificate",
        "args" => array(
             "name1" => "value1",
    $message = json_encode($message);

    The queue monitoring script would read the message, decode it, and, in this case, instantiate a new PDFCompletionCertificateCommand object then run its PDFCompletionCertificateCommand::setArgs() method passing in the args from the command, and then runs PDFCompletionCertificateCommand::execute() method to execute the command.

    Each command is its own separate class that implements a common interface so that the queue monitoring script can reliably run it. Then, adding a new job is simply a matter of creating a new class that implements this interface.

    The monitoring job, like I said, is an Upstart job so it runs as a daemon all the time. It checks the queue, sleeps for a few seconds, and then checks again. This way my jobs are run almost as soon as they arrive.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts