Is it wise to use PHP for a daemon?

Question

I wish to create a background process and I have been told these are usually written in C or something of that sort. I have recently found out PHP can be used to create a daemon and I was hoping to get some advice if I should make use of PHP in this way.

Here are my requirements for a daemon.

• Continuously check if a row has been added to MySQL database table
• Run FFmpeg commands on what was retrieved from database
• Insert output into MySQL table

I am not sure what else I can offer to help make this decision. Just to add, I have not done C before. Only Java and PHP and basic bash scripting.

Does it even make that much of a performance difference?

Please allow for my ignorance, I am learning! :)

Thanks all

Answer 1

If you combine the answers from Kent Fredric, tokenmacguy and Domster you get something useful.

php is probably not good for long execution times, so let's keep every execution cycle short and make sure the OS takes care of the cleanup of any memoryleaks. As a tool to start your php script cron can be a good tool. And if you do it like that, there is not much difference between languages.

However, the question still stands. Is php even capable to run as a normal daemon for long times (some years)? Or will assorted memoryleaks eat up all your ram and kill the system?

/Johan

Answer 2

One problem with properly daemonizing a PHP script is that PHP doesn't have interfaces to the dup() or dup2() syscalls, which are needed for detaching the file descriptors.

Answer 3

For what you've described, I would go with a daemon. Make sure that you stick a sleep in the poll loop, so that you don't bombard the database when there are no new tasks. A cronjob works better for workflow/report type of jobs, where there isn't some particular event that triggers the next run.

As mentioned, PHP has some problems with memory management. You need to be sure that you test your code for memory leaks, since these would build up over time, in a long running script. PHP doesn't have real garbage collection - It relies on reference counting, which means that cyclic references will cause leaks. If you're aware of this, you can code around it.

Answer 4

Running as a cron job with sensibly determined periodicity, a PHP script can do the job, and production stability is certainly achievable. You might want to limit the number of simultaneous FFMpeg instances, and be sure to have complete application logging and exception handling. I have implemented continuously running polling processes in Java, as well as the every-ten-minute cron'd PHP script, and both do the job nicely.

Answer 5

I'll be contrary and recommend you try the php daemon. It's apparently the language you know the best. You'll presumably incorporate a timer in any case, so you can duplicate the querying frequency on the database. There's really no penalty as long as you aren't naively looping on a query.

If it's something not executed frequently, you could alternatively run the php from cron, letting youor code drain the queue and then die.

But don't be afraid to stick with what you know best, as a first approximation.

Try not to use triggers. They'll impose unnecessary coupling, and they're no fun to test and debug.

Answer 6

A cron job and a little bit of bash scripting should be everything you need by the sounds of it. You can do things like:

$file=`mysqlquery -h server < "select file from table;"`
ffmpeg $file -fps 50 output.a etc.

so bash would be easier to write, port and maintain IMHO than to use PHP.