When designing client libraries to send data to our API, one of our top priorities is to make sure that none of our code affects the performance of your core application. That is tricky when you have a single-threaded, "shared-nothing" language like PHP. [...] Ideally, we like to keep the setup process minimal and address a wide variety of use cases. As long as it runs with PHP (and possibly a common script or two), you should be ready to dive right in. We ended up experimenting with three main approaches to make requests in PHP. Here's what we learned.

Their three suggestions don't involve external dependencies (like a queue server) and can operate pretty quickly:

• Opening a socket and closing it before waiting for a response
• Write to a log file (a pseudo-queue)
• Fork a curl process (through something like exec)

They each have small code examples included with them and explanations as to their plusses and minuses. For their needs, the "forked curl" solution worked out the best, but check out the other options too - you might have different needs.

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.

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.

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!

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.

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.

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.

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.

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.

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.