On his blog today Francois Zaninotto has a post that aims to introduce those with a PHP background to how Node.js works. In this first part of his series, he tries to explain the idea of event-driven programming - parallel processing of different parts of an application based on some action taken in the code.

For a PHP developer, asynchronicity is the most puzzling aspect of the Node.js runtime. It's simply a new way to write programs. And once you pass the first learning steps, event-driven programming opens a world of possibilities PHP programmers would never dream of. I'll try to explain you how it works, but first, let's talk about pasta.

In his "pasta" example, he shows how a typical PHP application would make a "Pan" object, call a "warm" action, "add olive oil", etc. All of this happens in sequence, though and takes 29 "minutes" to complete. To help things along, he implements an "EventLoop" class that handles tracking the timing and includes two methods to execute callbacks and delayed methods. He expands on this example with asynchronous objects and method calls to handle multiple things at once. He relates this to what Node.js offers - a built in event handling system, an included EventLoop object and native blocking I/O operations.

In a new post to his blog Gonzalo Ayuso has a suggestion for speeding up your scripts that use multiple database connections, possibly ones with larger queries that could take a while to run - asynchronous query handling.

That's the situation. A web application with 4 heavy queries. Yes I know you can use a cache or things like that but imagine you must perform the four queries yes or yes. As I say before the four database queries are heavy ones. 2 seconds per one. Do it sequentially, that's means our script will use at least 8 seconds (without adding the extra PHP time). Eight seconds are a huge time in a page load. So here I will show up a technique to speed up our website using asynchronous calls.

Since PHP doesn't really support threading, he works around it by creating a separate script for each of the queries (obviously only practical for special cases) as a self-contained unit. Then the "master" script that needs the results of the queries calls each of them via asynchronous curl class (simply named "Fork") that sends off the requests and waits for each result to come back as a json result set.

Kevin Schroeder has been conducting an informal poll about asynchronous computing in PHP applications and has posted some of the results (as well as the poll for those that didn't get their votes in) to his blog today.

Tis the season for Zendcon. I am going to be giving a talk at Zendcon called "Do You Queue". It will be about doing asynchronous computing in PHP. In order for me to gather some data I posted a twitpoll poll. The response has been pretty good. However, there have also been several misunderstandings as well.

He points out a few comments on the poll that talk about asynchronous processing being included in the language and dismiss it as something that other technology already does. He agrees that threads shouldn't be in PHP because it would break on of PHP's strongest features - the Shared Nothing architecture. Want to share your opinion? Vote on the poll and be heard!

Kevin Schroeder has posted excerpts from the sixth and seventh chapters from his "You Want To Do WHAT With PHP?" book.

Chapter 6 focuses on asynchronous processing and the excerpt talks about doing it with a little big of encryption on the side.

In the excerpt from Chapter 7 he looks at a more structured way to access files rather than just the random fopen or file_get_contents. There's a code example in this one showing how to get the header information off of a file for things like file type, last modified time, a header checksum and the file's permissions.

Daniel Jensen has a new post about using Gearman to do some simple database inserts asynchronously.

If you need to do a lot of inserts in your DB with a certain line of order they should be carried out in or with a clean-up script following after the inserts and you don't have to wait for a reply from MySQL, the answer to that problem might be this worker written in PHP for Gearman as an interface for your DB. A MySQL crash or a worker crash will have no impact on your inserts because they will just stay in the Gearman queue until the system is running again.

He includes a code snippet showing a sample database Gearman worker written in PHP to run simple database queries. His example uses a simple database connection (a basic wrapper around a mysql_query) and the line of code to run the worker.

New on his blog today Sameer Borate has a post looking at his method for making parallel connections with curl based on this library from Pete Wardens.

Most people use the 'easy' mode - in this mode when we issue multiple requests, the second request will not start until the first one is complete. This is known as synchronous execution, and this is the one we normally use. [...] In [multi] mode all requests can be handled in parallel or asynchronously. And it can be quite handy and time saving on many occasions.

He gives some code examples of how to use the library to simplify the curl connections and requests and pass the result off to a callback when it's done. His more practical example shows how to search for a set of terms on Google and return the results for output.

On the Ibuildings techPortal today they've posted the latest podcast recording from the 2009 Dutch PHP Conference sessions, Paul Reinheimer's look at maintaining state with Ajax ("in an Asynchronous World").

This talk will examine the two greatest problems in Ajax development (except for that pesky browser issue): Exactly what that "Asynchronous" word means, what problems it creates, and how they can be effectively managed, next the YUI Browser History object will be examined, finally handing control of Ajax applications back to the user via their familiar back button.

You can listen to this new episode in one of two ways - either by using the in-page player or you can download the mp3 directly.

Padraic Brady has posted part three of his look at asynchronous processing in PHP applications today. The previous two parts introduced you to the topic and got you ready to work with child processes in a Zend Framework application. This latest part gets into the code showing how to fork the processes and handle communication between them.

With the theory heavy portion of the series out of the way, we can begin to explore the various implementation possibilities. In this part, we will examine implementing Asynchronous Processing using a child process, i.e. a separate PHP process we create from our application during a request. We'll analyse this implementation option before introducing the source code so we may understand its advantages and disadvantages.

He looks at both the advantages and disadvantages of processing with child processes and suggests a method to get a handle on the processes rather than just spawning new processes - forking. Some basic code examples are included, using the popen function to open the new child process and a Zend Framework example.

In the second part of his series looking at asynchronous processing in PHP applications, Padraic Brady lays the ground work for the third part and shows how to work with command line Zend Framework applications.

Part 2 is a tangential detour into how to make a Zend Framework based application accessible from the command line before we delve into examples using this in future parts of the series. If you are not a Zend Framework user, I'm sure you can find relevant material online for your own preferred framework though the ZF pieces may still have some usefulness in understanding the approach from an MVC perspective.

In his examples he skips over the basics of using a command line application and jumps right to things like argument handling, creating a custom router and making a custom "calling script" to handle the configuration of the CLI application.

Padraic Brady has started up a new series of posts to his blog on the topic of asynchronous processing with PHP.

Imagine a world where clients will give up on receiving responses from your application in mere seconds, where failed emails will give rise to complaints and lost business, where there exist tasks that must be performed regularly regardless of how many requests your application receives. This is not a fantasy world, it's reality. [...] Asynchronous processing is a method of performing tasks outside the loop of the current request. Basically, you offload the task to another process, leaving the process serving the request free to respond quickly and without delay.

He talks about some of the problems that asynchronous processing solves (like tasks that must be completed despite errors) and starts to outline a simple processing structure with child processes and task handling.