In my opinion, a lot of the hatred that PHP receives misses the utter basic point: PHP is meant to die. It doesn't mean that a perfectly capable (to some extent) programming language will disappear into nothingness, it just means that your PHP code can't run forever. Now, 13 years after the first official release in 2000, that concept still looks valid to me.

He talks about some of the "dying" that PHP is good at (like making general website-related requests) but notes that if you try to have it do much more, PHP acts up. He points to the complexity of web-based applications and notes that, while PHP is good for some of it, it's not a fit for all functionality. He also covers the bringing of processes to the foreground that are best left in the background and how - despite the best of intentions - making a PHP daemon to solve the problem isn't a viable option.

Do you see the pattern? I've inherited projects where PHP was used for daemons or other stuff that's not just regular websites (yes, I'm a hired keyboard), and all of them shared that same problem. No matter how good or clever your idea looked on paper, if you want to keep the processes running forever they will crash, and will do it really fast under load, because of known or unknown reasons. That's nothing you can really control, it's because PHP is meant to die. The basic implementation, the core feature of the language, is to be suicidal, no matter what.

The performance of a web application plays a critical role in how an application is perceived by its users. It is important to measure it, identify the causes if it changes and react swiftly to any unexpected changes. This article describes an industry leading tool, New Relic, and how it can be used to monitor and improve your site performance. [...] New Relic is a real-time application monitoring service, providing various metrics about the performance of your production site, covering everything from application database queries through to the time it takes for the end-user to view a page.

They walk you through a "getting started" with the tool and how to get it running on your server - for PHP this means installing an "agent" extension and a local daemon for it to feed information back to. They then get into some of the data New Relic provides including application performance details, browser information, throughput and an Apdex score.

There is a special group of applications that require a different PHP script execution model. [...] All of [these special] applications need to be run in the background as daemons - something that PHP was never designed/supposed to be good at. The plain C language is a weapon of choice when it comes to writing a daemon implementation, but then again, if the application in question does not depend on high performance and concurrency - PHP can do the job quite well.

He talks about using the command line interface to run the scripts, creating the while loop to keep execution going and creating the non-blocking socket so that the script can accept new client connections. He also mentions using upstart to run the script in the background and the proctitle PECL extension to give the process a custom name in the process list. He also touches on log files and forking/parallel processing.

One of the many things you don't often do with PHP (actually, I'm not sure you do this much with any language) is daemonize a process. A daemon is program that runs in the background (read more here). On Unix systems, processes are usually created by forking the init process and then manipulating the process to your liking. To create a daemon though, you need to get the init process to adopt your process. To do that, as soon as you fork the parent process, you kill the parent. Since you child process is parent-less, the init process generally adopts it. Once that happens, your process has been daemonized.

He uses the pcntl_fork function to spawn off the child process, detach it from a terminal window, create a ".pid" file so the system knows about it and then, of course, have the child script do something.

PHP is a language generally not suited for running daemons. That said, PHP can do it, and in certain circumstances does it sufficiently for the job. In this chapter we look at some of the things you need to know about to build a PHP-based daemon. This excerpt doesn't feature any code, but it does set the foundation for why I think PHP is fine for daemons in some circumstances.

The excerpt is mainly the first part of the chapter that just introduces the idea of daemons including some of the right and wrong uses, using the right tool for the job and how using PHP for a daemon can help with needs in a place where PHP might already be a norm.

Sometimes things just get too heavy for a straight forward approach. Memory usage might be too high or interaction might be delayed. In this case it might make sense to queue the task up for later execution.

The technique uses beanstalkd as a messaging queue to handle the requests based on the user's request via the interface the beanstalkd library provides. Then, to keep the queue running in the background and available, he uses daemotools to run a worker process. You can download the complete code for a working example.

If you want to tell me I'm crazy, you can post it in a comment here, it makes me happy. I had some reasons to dislike bind9 which finally made me write my own DNS daemon, and I'll explain that here. My need was to have a stable dynamic DNS server working in most environments, with an easy to configure master/slave relationship (with realtime synchronization), and a way to change records instantly from PHP...

Rather than using the (slightly unstable) dlz technology to pull the information from a MySQL database, he opted to roll his own that includes support for:

• RFC 1035 standards
• realtime data update
• slave/master relationship (with a keepalive connection)

Want to try it out for yourself? Drop him a line and ask about it!

He's also run some statistics on the performance of the daemon as compared to the standard BIND installation and come up with some instructions on how you can install and configure your own instance.

Ever wanted to give meaningful names to your processes when you pcntl_fork() with PHP ? proctitle is the extension you're looking for! Adapted from bug report #29479 and code initially wrote by Midom for Wikipedia, the proctitle extension allows for a process to change its own displayed title in the system's process list.

The extension (seen in action here) is an interface for making different sorts of daemons, including the ability to give them names. You can check out the project here.

Everyone knows PHP can be used to create websites. But it can also be used to create desktop applications and commandline tools. And now with a class called System_Daemon, you can even create daemons using nothing but PHP. And did I mention it was easy?

He starts with a definition ("a linux program that runs in the background") and why PHP makes a good language choice for creating them. His example uses the System_Daemon PEAR class to do most of the heavy lifting. To use it, you only need to include it at the top of the script and make two calls to the setOption and start methods to have the rest of the code all set to run as a daemon.

The example code sets up a daemon complete with support for command-line arguments and the ability to be run from init.d on the local system.

nanoFTPd is an ftp daemon written in php. as of version 4.2.0, php supports the command-line interface (stable since 4.3.0), which nanoFTPd relies on. nanoFTPd is modular, so it's easy to add custom modules and other stuff, like different database interfaces (currently supports mysql and postgresql).

Features of the app include user authentication via a database or text file, dynamic IP support, and most of the usual FTP goodies you're used to in a server. You'll need at least PHP 4.2.0 to get it up and running, but configuration is simple and installations it just as easy. You can grab the software from their website.