In a post to his site Sergey Zhuk shares his opinion on asynchronous PHP and why it's in such demand these days in web-based applications.

Asynchronous programming is on demand today. Especially in web-development where responsiveness of the application plays a huge role. No one wants to waste their time and to wait for a freezing application, while you are performing some database queries, sending an email or running some other potentially long-running tasks.

Users want to receive responses to their actions, and they want these responses immediately. When your application becomes slow, you start losing your clients. Once a user has to deal with a freezing application, in most cases he or she simply closes it and never returns. When the UI freezes from the user’s point of view, it is not clear if your application is broken, or it is performing some long-running task and requires some time for it.

He goes on to talk about the importance of responsiveness in web applications and clearing up the difference between running tasks in parallel and running them asynchronously. He also talks briefly about the use of asynchronous processing on the backend and how it compares to other technology (like Node.js and Go) that have built-in asynchronous processing.

Frank de Jonge has a tutorial posted to his site showing you how to use partitioning for concurrency in optimizing the business logic processing in your PHP applications.

With new ways of dealing with problems, new problems emerge. When the solution space evolves, so do the problems we deal with. One could say we only exchange one type of problem with another.

[...] Such constraints might steer you towards a synchronous solution, but a deeper understanding of a given domain might allow for an alternative approach. The need for synchronous processing is not always as final as it may seem. Sequential handling may only be a requirement within a certain context. A context may be defined by anything related to a single user, group, or even a process.

He talks some about concurrent processing versus sequential processing and how, sometimes, pure versions of either aren't exactly the right fit. Instead he proposes a system where multiple streams could be used with synchronous handling keeping with the concurrency between the streams. He illustrates his point with a "silly chat application" with the requirement that users all get their emails in order. In his proposal he starts with a standard single thread/multiple workers scenario but points out that this may lead to messages being out of order depending on the processing time for the worker it ends up on. He refactors this into a system that uses the parallel processing instead, including the PHP code that's required to make it work.

The SitePoint PHP blog has posted a tutorial that introduces some of the fundamentals of parallel programming in PHP. In their examples they make use of the pthreads extension to help bring simpler parallel programming to the language (otherwise you'd have to do odd things with shell commands and foreground/background controls).

PHP developers seem to rarely utilise parallelism. The appeal of the simplicity of synchronous, single-threaded programming certainly is high, but sometimes the usage of a little concurrency can bring some worthwhile performance improvements.

In this article, we will be taking a look at how threading can be achieved in PHP with the pthreads extension. This will require a ZTS (Zend Thread Safety) version of PHP 7.x installed, along with the pthreads v3 installed.

Despite the article being about the use of pthreads, it starts out talking about when not to use it, possibly saving you some time in the long run. With that out of the way it then starts in on the handling of "on-off tasks" with an example of fetching the "title" value from Google.com. This is then enhanced showing how to use the "Threaded" base class to define other classes that can be used inside of threads. The article moves on covering other topics including:

• recycling threads
• pthreads and (im)mutability
• synchronization of threads

Each item in the list comes with plenty of example code showing you how to create the classes that execute the threads and the output they should generate.

In his latest post Derick Rethans shows how to parallelize document retrieval from a MongoDB database via PHP. This makes it possible to speed up the read operation caused by reading each item one at a time.

MongoDB 2.6 has a new feature that allows you to read all the documents from one collection with multiple cursors in parallel. This is done through a database command called parallelCollectionScan. The idea behind it is that it is faster then reading all the documents in a collection sequentially.

He includes an example snippet that enables the "parallelCollectionScan" handling for a "cities" collection and the resulting output. He shows how to manually create MongoCommandCursors (or let the driver do it for you) and use PHP's own MultipleIterator to process all of the cursors at essentially the same time.

On the VG Tech blog today Espen Hovlandsdal has a quick tutorial showing you how to run cURL requests in parallel using the curl_multi_* functions included in PHP.

Ever had to request multiple HTTP-resources in your web application? Often, you need data from one request to be able to request the second – in this case there is little you can do but wait for the first to return. However, if the requests are not dependent on each other, you can use a pretty cool trick: curl_multi_*.

He first gives a single-threat example, showing how you might loop through a set of URLs to make the request and get the response. As an alternative, he shows the "multi" version right after. It sets up a "queue" of handles to different requests and executes them until they stop returning data. He also includes an example using the Guzzle HTTP client that makes it look cleaner and wraps some additional functionality around the requests.

On NetTuts.com today there's a new tutorial showing you how to use ParaTest for PHPUnit to execute your tests in parallel instead of the usual inline, in-order method.

PHPUnit has hinted at parallelism since 2007, but, in the meantime, our tests continue to run slowly. Time is money, right? ParaTest is a tool that sits on top of PHPUnit and allows you to run tests in parallel without the use of extensions. This is an ideal candidate for functional (i.e Selenium) tests and other long-running processes.

ParaTest operates as a separate binary that can easily be installed via Composer. They walk you through the install and show you what kind of options it lets you provide (like number of processes and the path to the PHPUnit executable). They show you how to write some parallel tests, five of them, each that sleeps for a certain amount of time. They also look at another tool that could help run your tests in parallel, Paraunit. They finish off the post with a look at some functional testing examples using Selenium, handling race conditions and some of the future plans for ParaTest's future.

On DZone.com today there's an update about recent additions to Paratest, the parallel PHPUnit test runner (created by Brian Scaturro). He talks some about the benefits of running tests in parallel and shares some of the recent contributions to the project from other developers.

I've already written about my experiments with Paratest. Paratest is a PHPUnit wrapper that allows you to run tests written for PHPUnit in parallel, making us of multiple processes running on the same machine. In a world where cycle time is an important metric, trading resources to get the test suite to finish earlier is a net gain; especially when you're stepping on unstable stones and run the suite very often.

He (Giorgio Sironi) has contributed a new test runner to the project - the "WrapperRunner" that limits the number of processes spawned by the parallel testing tool. Another contribution came from Dimitris Baltas involving the addition of a TEST_TOKEN variable that can be used to uniquely identify each process as they're executing.

On DZone.com Giorgio Sironi has written up a new tutorial showing how to use parallelism with PHPUnit to execute multiple sets of tests at once, hoping for a performance gain.

Of course the cost of coordinating different processes is always going to be present, so we will never reach the theoretical speedup. I'll report later in this article some simulations. The most important constraints come from the design of our test suites. I can only think of two categories of tests as easily parallelizable: unit tests and Selenium tests.

He mentions one specific issue to watch out for - race conditions between the test sets (using the same backend resources). To help solve the issue, he recommends looking into Paratest, a tool that sits on top of PHPUnit and handles the execution of the tests in parallel. He creates some sample tests (they just compute values) and compares the runs of them in single- and multiple-process modes. The difference is a twenty-five percent drop in execution time for the parallel test runs.

In a recent post to his blog David Müller has taken a look at parallel processing in PHP using a few different methods - system calls, fork, and curl.

Since PHP does not offer native threads, we have to get creative to do parallel processing. I will introduce 3 fundamentally different concepts to emulate multithreading as good as possible.

For each of the technologies mentioned above, he provides a simple bit of sample code that does simple tasks like echoing out strings and writing to files. He also includes some benchmarks (take them with a grain of salt) of the three different methods showing how many iterations they could run through in ten seconds. He includes the benchmarking script if you'd like to try it out yourself.

On his blog today Matthew Weier O'Phinney talks about how to run mod_php and FastCGI side-by-side on a Zend Server instance.

I installed Zend Server some time ago, so I'm still on a PHP 5.2 mod_php binary. I have several PHP 5.3 binaries compiled and installed locally for running unit tests and sample scripts already -- so the question was how to keep my 5.2 mod_php running while simultaneously allowing the ability to run selected vhosts in 5.3? The answer can be summed up in one acronym: FastCGI.

He shows how to enable FastCGI in Apache (on Ubuntu), make a virtual host for your site and create a "cgi-bin" directory to contain the script(s) for your PHP versions as CGIs.