PHP in the Dark
presentation, console, daemon, ipc, cli, php
Recently I presented a talk called "PHP in the Dark" about php in console scripts, daemons and concurrent processes. When preparing for the talk, I noticed I had a massive amount of information, too much for just a talk...
When we say PHP, most people automatically think about websites or web applications. And let's be honest, that's what PHP was built for and exiles in. But sometimes you need to support your web application with "things" running in the background. Some examples could be:
• You want invoices created and sent out every first day of the month;
• You need news feeds imported and stored in your database;
• You generate csv reports during the night to be sent to a third party for import;
• You might need large sets of data aggregated and re-organized in smaller sets of data that are easier in use for reporting purposes;
• And much more...
Whatever your reasons, these are things that you can't, don't want to or shouldn't run in the browser. PHP allows you to run scripts on the command line using php-cli. Using crontab you can schedule scripts to run at specific dates and times. And the great thing is that you can reuse all your classes and logic build for your application in a non-webserver environment.
Sometimes this isn't enough and you need to take it one step further. You might for example have a mailing application and need to sent out millions of mails a day. With your web application (back-office) you will create a new mailing and specify who the recipients are. As soon as the mailing is created, you want it sent out. The browser isn't really an option, unless you want to keep your browser window open until all mails have been sent. A scheduled cronjob could do the work, but you always have a time gap before the script starts running. You might even run into problems when cron tries to start a script while the previous run isn't finished yet.
With daemons you can have a script that runs autonomously in the background and checks for triggers constantly. Once it gets a signal to start processing a mailing, he will get busy. If he has no work, he will just do nothing and wait for work to come his way. If the daemon receives a very high load of work, he could even decide to create child or worker processes and split up the work among them. This way the data is processed in parallel which is a lot faster than just sending out mail after mail after mail.
With daemons you can do a lot of things, but you can also majorly screw up. In this respect there are a number of steps that tell you how to create a daemon properly. You might also need to send signals to reinitialize your daemon or to stop it. If you work with worker processes, you might need ways to communicate and share data. IPC (short for Inter-Process Communication offers you techniques to just do that.
I will be writing some detailed posts over the coming weeks, so far I finished:
- Input/Output: talks about input/output handling in command line scripts
- Layout Helpers: talks about adding tables, color and progressbars in your scripts
While waiting for the other posts, you can see the presentation here:
+32 475 62.42.64
Eric Cambray
2011-02-24 16:55