Niklas Keller has a post to his site covering the magic behind async PHP and how it can help your application gain some performance by working around the typical PHP execution flow.

Async PHP allows a massive speedup of applications by leveraging non-blocking I/O. It allows making multiple HTTP requests in parallel or any other way of I/O multiplexing. But what’s the magic behind it? How does it actually work?

He starts with a brief explanation of the difference between blocking and non-blocking I/O, pointing out that the main difference is the use of streams. He includes a bit of code to help illustrate but moves quickly on to talking about the Amp PHP package. This library allows for easier (and faster) development of non-blocking processes using an event loop. He also shares a package that was created to help make it even simpler by providing an abstraction layer on top of the Input and Output streams.

Sergey Zhuk has posted the third part of his series covering the creation of a Memcached client using ReactPHP has the base and allowing for asynchronous operations. In this latest part of the series (part three) he focuses on emitting events for various actions/results in the client code.

In the previous article, we have faced with a problem: how to deal with a broken connection. Now, when the connection is closed all pending requests are rejected with the ConnectionClosedException. If we want to handle this situation we need to attach onRejected handlers to all promises because we can’t guess in advance which one will be the problem.

This [example] code already looks too complex, but also there is no way to find out if the connection was broken or we have manually close it. So, it becomes clear that we need a completely different approach.

He then shows how to make use of this event library to emit events at certain points in the client's state. He includes code examples showing how to use the emit method to throw the event focusing on handling when there's connection issues.

Sergey Zhuk has posted the second part of his series covering the creation of a ReactPHP-based memcached client for asynchronous cache handling. In part one he set up some of the basic structure of the client and got it to a working state. In this latest part he expands on that base and improved the error and connection handling to make it more robust.

In the previous article, we have created a simple streaming Memcached client for ReactPHP ecosystem. It can connect to Memcached server, execute commands and asynchronously return results. In this article we are going to implement some improvements: connection handling [and] errors handling.

He then goes through and makes changes to allow for correct handling of the connection closing where it can either be closed by an option you specify or a forced close from the server. On the error handling side he shows how to handle invalid commands (throwing a WrongCommandException) and a failed command, such as when the value couldn't be stored for one reason or another.

In this new post to his site Herberto Graca has posted the latest part of his "The Software Architecture Chronicles* series, focusing this time on event-driven architectures.

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

Using events to design applications is a practice that seems to be around since the late 1980s. We can use events anywhere in the frontend or backend. When a button is pressed, when some data changes or some backend action is performed.

But what is it exactly? When should we use it and how? What are the downsides?

He starts by talking about the "what", "when" and "why" of using events to drive the architecture of the system, going into each of the topics in a bit more depth:

• To decouple components
• To perform async tasks
• To keep track of state changes (audit log)

He then goes on to talk about common patterns for event-driven applications including event notification, event-carried state transfer and event sourcing.

In a post to his site Niklas Keller provides an introduction to generators in PHP. Generators provide more "just in time" functionality for looping (iterators) without the need to create a separate class to handle it.

Generators have been added to PHP in version 5.5, yet the have received rather low attention. The PHP 5.5 migration guide introduced them as way to implement simple iterators.

He shows the comparison of generators versus a foreach loop and discusses how the yield statement works and what benefits the generator gives over normal looping. He refactors the example to get a clearer picture into what's happening inside the generator, outputting a few strings when the next value is fetched. He then suggests that generators that are just used as iterators are "boring" and covers some more interesting features and uses (including handling of async operations).

On the Hack blog there's a new post talking about async, a feature in Hack that allows for code to "cooperatively multitask". This gives the language a way to keep moving on in the execution without having to wait for things like database queries or remote file fetches to finish.

This is somewhat similar to threading, in that multiple code paths are executed in parallel, however it avoids the lock contention issues common to multithreaded code by only actually executing one section at any given moment. “What’s the use of that?”, I hear you ask. You’re still bound to one CPU, so it should take the same amount of time to execute your code, right? Well, that’s technically true, but script code execution isn’t the only thing causing latency in your application. The biggest piece of it probably comes from waiting for backend databases to respond to queries.

She gives the example of pulling in a remote file (HTTPS, where there's a bit more latency) and how to use async, await, WaitHandle, and Awaitable to work around the timing issue. She shows how to make a method asynchronous and how to join the results of the operation back up with the rest of the script. This includes the use of various "handles" including RescheduleWaitHandle, SleepWaitHandle and the AwaitAllWaitHandle. She shows the integration of a custom cURL handler that makes use of this processing, marked async, to multithread the requests to the remote server(s).