On the Tideways blog Benjamin Eberlei has written up a post showing how to use php-fpm as a "poor man's queue" system, making it easier to hand off requests to be worked on out of band without having to install other software.

There are many tasks that a web-request should not perform directly so the user doesn't have to wait many seconds for a response. [...] The usual advice you find on the internet is to setup a queue such as RabbitMQ, Redis, Kafka, Gearman or Beanstalkd. But this means another service that you need to install, setup, maintain and monitor. With some of the queue systems operating them includes a steep learning phase that requires time and money for additional hardware.

But maybe you just need a poor mans version of an asynchronous queue without all the overhead? Then why not just use PHP-FPM itself?

He admits that it's more of an "experimental approach" but feels like it could be a viable option for the php-fpm users out there. He then shows how to use the hollodotme/fast-cgi-client library to execute an asynchronous request for a "SendEmail" command. The request is then passed off to another PHP-FPM worker for processing without the user having to wait on a result. He ends the post with a few words of warning about using this approach and some other methods for getting around the offloading of longer processing.

The Tideways blog has a post sharing things you can do in PHP to work with HTTP client timeouts in things that use the PHP sockets and streams.

Timeouts are a rarely discussed topic and neglected in many applications, even though they can have a huge effect on your site during times of high load and when dependent services are slow. For microservice architectures timeouts are important to avoid cascading failures when a service is down.

The default socket timeout in PHP is 60 seconds. HTTP requests performed with for example file_get_contents, fopen, SOAPClient or DOMDocument::load are using this timeout INI setting to decide how long to wait for a response.

He talks some about how these timeouts can effect your script and some of the common reactions (in code) to them happening. He then shows how to configure these timeouts to match the needs of you application in a few ways:

• globally in the ini configuration
• on a per-call basis in a stream_context_create call
• changing the load timeout for DOMDocument::load
• updating the setting for calls with SOAPClient
• changing the timeout on cURL extension calls

Each item on the list comes with the code/settings needed to make the change.

In a new post to his site Brian Moon has shared a problem he had with sockets and timeouts and having them perform the same way every time. He walks through the symptoms he was seeing and provides his own solution in the end.

So, it seems that when you try and connect to an IP that is routable on the network, but not answering, the TCP stack has some built in timeouts that are not obvious. This differs from trying to connect to an IP address that is up, but not listening on a given port. [...] After a lot of messing around, a coworker pointed out that in production, the failures were happening for an IP that was routable on the network, but that had no host listening on the IP.

After some testing, Brian figured out that his problem was using localhost for testing and not an actual non-host server. He made the switch and figured out how to set the timeouts low and work with error state checking to make things more stable. He explains a bit more about how the code in his solution works. You can find his solution in this gist on GitHub.

While not a recent article, this post from Saran Chamling is definitely interesting. In it he shows you how to create a real-time chat by combining PHP and WebSockets.

The WebSocket is a feature of HTML5 for establishing a socket connections between a web browser and a server, once the connection has been established with the server, all WebSocket data (frames) are sent directly over a socket rather than usual HTTP response and requests, giving us much faster and persistent communication between a web browser and a server. Let’s create a simple chat system using this cool technology (HTML5 WebSocket and PHP).

He includes all the code you'll need to get things up and running, starting from the WebSocket side. With a simple socket connection and some jQuery to control it, the system connects to the backend PHP script. The PHP script reads directly from the socket (using the socket_* functions) and binds to it, waiting for incoming requests. There's also some sample code showing how to work with the "handshake" between the WebSocket and PHP and how to respond. If you want something a bit easier to work with and more functional, consider checking out Ratchet, a WebSocket server for PHP.

In his previous post ("PHP was meant to die") the point was made that PHP isn't really designed as a language to handle long running processes very well. It's made to handle a few operations and then die at the end of the request. In this follow up post he talks more about using PHP for long running processes and a library that could help.

Yes, I already acknowledged that PHP has a garbage collection implementation starting 5.3.0 and up (opt-in or opt-out, that’s not the problem). I also acknowledge that garbage collection works, and is able to take care of most circular references just fine. [...] Anyway, as previously stated too, garbage collection is a great thing, but not enough for PHP. It’s a borrowed feature that does not play well with old fundamental decisions inherited from the original design. Garbage collection is not a magical solution for every problem, like many tried to argue about. Let’s illustrate with another example.

His example uses the React PHP library (a non-blocking I/O platform) to handle a lot of incoming data to a port and report back some memory usage and limit settings. He explains a bit about what's happening and shares the results of the test, including the end result - a fatal error when the memory limit was hit. He still comes to the same conclusion, ultimately...PHP is just not the language to use for long-running processes that do any large amount of work.

On PHPMaster.com there's a new tutorial that introduces you to React, the PHP-based event-driven non-blocking socket tool that's similar to some of the functionality Node.js provides. The article is a very basic introduction but can help get your feet wet with the tool.

For the past couple of years, Node.js has been drawing increasing amounts of attention as a promising web technology. While it has some strengths, like being event driven, some people just want to stick to PHP. For over a year now, however, there has been a similar project for PHP named React. React is mostly coded by Igor Wiedler, who is also a prominent contributor to the Silex framework. While reading through the React examples, it really does look similar to Node.js.

Included in the post are the instructions on how to get the latest version of React (via Composer) and the code to create a sample server that just writes out a string with a counter for the number of requests made. There's also an example of a "keystroke logger" for all data that's coming across the connection. The author (Igor) notes, however, that he wouldn't recommend using React in production, though, as its target is mostly those working with "cutting-edge technologies" rather than more stable applications.

On the Segment.io blog there's a new post by Calvin talking about making asyncronous requests in PHP and three different approaches you could use, depending on your situation.

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.

Nikita Popov has a new post to his blog about a new feature that will be coming in PHP 5.5 and how to use them, coroutines and generators, in an example application.

Coroutines on the other hand have received relatively little attention. The reason is that coroutines are both a lot more powerful and a lot harder to understand and explain. In this article I'd like to guide you through an implementation of a task scheduler using coroutines, so you can get a feeling for the stuff that they allow you to do. I'll start off with a few introductory sections. If you feel like you already got a good grasp of the basics behind generators and coroutines, then you can jump straight to the "Cooperative multitasking" section.

He starts with a look at generators, a piece of functionality that will allow PHP to, for example, more easily create iterators "on the fly." He then moves on to coroutines, added functions that you have two-way communication with generators instead of just pulling data from them. With the basics out of the way, he gets into the "cooperative multitasking" and a sample socket-based server he implements using some of the concepts.

In one of his recent posts Christoph Hochstrasser looks at socket programming done the right way, complete with code examples showing both client and server setups.

When writing about socket programming with PHP, nearly all articles are about the Socket Extension, despite it's the unfriendliest and most cumbersome way to work with Sockets in modern PHP. Let me introduce you to something, which apparently is pretty unknown among PHP programmers.

He starts off by introducing the concept of a socket (for those that are beginners on the topic) and talks about two of the major ways to work with them - the Socket extension and Streams. He shows how to use the stream_socket_client_* functions to connect to a remote server and make a HTTP request for the base page. He also shows the other side of things, making a simple "echo" server that binds to port 1337.

On the BinaryTides.com site there's a recent tutorial showing you how to effectively use sockets in your PHP applications, complete with incoming and outgoing examples.

This is a quick guide/tutorial to learning socket programming in php. Socket programming php is very similar to C. Most functions are similar in names, parameters and output. However unlike C, socket programs written in php would run the same way on any os that has php installed. So the code does not need any platform specific changes (mostly).

They start with the basics - creating a socket, connecting to a server and sending out information over the connection. They also include the code examples showing how to pull in data from the socket. Their example socket is set up to be a simplistic web server, returning data according to the standards for a normal GET request. They make a mini-server out of it, getting to to accept requests on a bound socket.