Kurt Payne has a new post to his blog showing how you can unit test your process forking in your PHP application (pcntl).

At some point, many php developers turn to the pcntl functions in php to write a daemon, or server, or simulate threading. But how do you unit test this with complete code coverage? [...] We need to engage some black arts php extensions to make this happen. An installation guide follows, and the post ends with a complete listing of the unit test.

He uses the test_helpers extension (as provided by Sebastian Bergmann) and Runkit to allow the test to define new methods copying the current pcntl methods and mocks up the responses. Tests are included to check the parent of a process, checking the children of a process and testing that a fork could be made. Hes's even included visual proof of this working.

On the Perplexed Labs blog there's a recent post looking at how to fork processes in PHP with the help of the pcntl_fork function and the process management extension.

Let's say you want to take advantage of more than one core for a given process. Perhaps it performs many intensive computations and on a single core would take an hour to run. Since a PHP process is single threaded you won't optimally take advantage of the available multi-core resources you may have. Fortunately, via the Process Control (PCNTL) extension, PHP provides a way to fork new child processes.

He gives a quick snippet of code showing how to spawn off a few new processes, get their process IDs and watches a max number of children until one dies (then starts another).

On the Ibuildings blog today there's a new post from Martin Roest looking at parallel processing in PHP scripts and how it can help you with performance and simplifying your applications.

The idea of parallel processing is when you take an atomic transaction or operation called a 'process' and run a couple of those at the same time. [...] In this example I had a PHP CLI script. The purpose of this script was to process remote documents and save it local. It fetched the document from a remote location, processed it and saved the result local - let's call this the transaction. Transactions were done sequentially. It took about 1 second for a transaction to complete and the script had to do roughly 3500 transactions.

Obviously, this script/testing method was not very effective, so he went searching for an alternative. The best option came in the shape of forking processes - spawning off a separate script (via PHP's forking functionality) to do the work on one or multiple entries. It uses the pcntl_fork and pcntl_waitpid functions to spawn and manage these children. Once they're all finished - working in parallel - they return back to the main script to wait for the slower ones to catch up.

Evert Pot has a quick post showing how you can make your code fork MySQL connections for better performance.

For some of our long-running processes we use PHP. It makes total sense from our perspective, because we can re-use all our existing business logic from our main PHP web application. To make things more efficient, I recently started some work on using forks and have a couple of worker processes around.

His sample script makes use of the pcntl_fork and pcntl_wait functions in PHP to spawn off processes that will be closed off when no longer needed.