On the Delicious Brains site they've posted a tutorial showing how to create a command line daemon that will emulate the Amazon Web Services SQSD handling. The SQSD is a worker daemon service that Amazon offers as a part of its Elastic Beanstalk support.

Sometimes when you’re building a project there are parts of the architecture that exist on production that don’t exist on your development machine. Those missing parts (like proprietary software that’s specific to your hosting provider) can sometimes mean unwelcome surprises when you deploy to production.

Recently as part of my work on Mergebot, I decided to address this. My local machine was missing the AWS Elastic Beanstalk Worker Environment SQS daemon (known as SQSD). AWS isn’t open source so there’s, unfortunately, no official way to replicate it. So I decided to build a small PHP command line (CLI) app to attempt to replicate its functionality. In this article, I’m going to cover some of the aspects of creating a command line app in PHP and explain how I implemented them for my replica SQSD CLI.

He starts off with a brief overview of the Laravel queue worker and how it compares to the SQSD functionality. He then starts in on the code to create the daemon (outside of a framework) and adding in the while loop to keep it running as a daemon making use of the SQSD Worker class as a base. The post ends with some instructions on packaging up the command line tool using the phar functionality already included in the PHP language.

Continuing his series about new functionality in Laravel v5.3 Matt Stauffer has posted this quick article covering updates to the queue worker functionality.

Queues are one of those tools in Laravel that everyone knows is there, but very few people understand deeply. It's understandable--Laravel is often the first place folks have run into queues, and to be honest, they're not simple.

Thankfully, very little has changed on a user-facing front with regard to how queues work in Laravel 5.3.

One of the main updates is that the "listen" command is now "work" and the action then runs as a daemon by default instead of requiring the command to be long-running. He talks about the difference in this shift and how something like Supervisor can now be used to manage the daemon (including some documentation specific to Laravel). He finishes the post looking at what has changed "under the hood" and the benefits the changes bring.

One of the latest offerings in the Laravel ecosystem, Laravel Valet, was released this past week. It makes setup of new applications simpler and even allows tunneling back from the public web to a local system for easy sharing. In this post to his site Mohamed Said takes a look at the "magic" behind Valet and how it does what it does.

So yesterday Taylor Otwell and Adam Wathan released Laravel Valet, it's simply a tool that helps OS X users easily run their websites locally for development purposes, without the need to configure anything each time a new project needs to be created.

The idea behind valet is that it configures PHP's built-in web server to always run in the background when the operating system starts, then it proxies all requests to a given domain to point to your localhost 127.0.0.1

He starts by helping you get the tool downloaded (via Composer) and what happens when you run the valet install command. He gets into the detail of each piece that valet sets up:

• the OS X daemon to run the PHP built-in server
• the Valet configuration files
• Dnsmasq (a DNS server)

He then talks about how handles the requests for your local ".dev" sites and the "drivers" it uses to decide which site to serve up.

Gonzalo Ayuso has a new post to his site today showing how to create a TCP server daemon with PHP with help from the Ratchet toolset. Ratchet is a library that makes it easier to work with WebSockets directly from PHP.

In my daily work I normally play a lot with TCP servers, clients and things like that. I like to use Linux’s xinet.d daemon to handle the TCP ports. I’ve also written something about it. This approach works fine. The problem appears when we call intensively our xinet.d server. It creates one PHP instance per request. It isn’t a problem with one request in, for example, 3 seconds, but if we need to handle 10 requests per second our server load will grow. The solution: a dedicated server.

In a setup similar to how Silex registers callbacks, he's created a PHP-based server that listens on whatever ports are defined for incoming connections and processes the data accordingly. He includes several code samples that show it in use, both in simple request handling and more complex configurations based off of a YAML file definition. He ends the post with a method he uses to "emulate" threading in his processing with the help of a Silex app and HTTP requests to hand off the processed and remove the blocking problem PHP introduces.

Rob Aley pointed me towards a new ebook he's created that wants to help you understand what kinds of things PHP can do "beyond the web" and the usual web-based applications - PHP Beyond the Web.

Leverage your existing web based PHP skills to write all types of software. CLI scripts, desktop software, network servers and more - this book will give you the tools, techniques and background necessary to write just about any type of software you can think of, using the PHP you know.

The book covers topics like interactive shell scripts, system daemons and desktop software. It also looks at some more general development topics like licensing, deployment and system interactions. If this sounds interesting and you want a sample of the content, check out the table of contents or the sample chapter.

In this new post, titled "PHP is meant to die", the author looks at one weakness he sees in the PHP language - how PHP handles long running scripts and functionality.

In my opinion, a lot of the hatred that PHP receives misses the utter basic point: PHP is meant to die. It doesn’t mean that a perfectly capable (to some extent) programming language will disappear into nothingness, it just means that your PHP code can’t run forever. Now, 13 years after the first official release in 2000, that concept still looks valid to me.

He talks about some of the "dying" that PHP is good at (like making general website-related requests) but notes that if you try to have it do much more, PHP acts up. He points to the complexity of web-based applications and notes that, while PHP is good for some of it, it's not a fit for all functionality. He also covers the bringing of processes to the foreground that are best left in the background and how - despite the best of intentions - making a PHP daemon to solve the problem isn't a viable option.

Do you see the pattern? I’ve inherited projects where PHP was used for daemons or other stuff that’s not just regular websites (yes, I’m a hired keyboard), and all of them shared that same problem. No matter how good or clever your idea looked on paper, if you want to keep the processes running forever they will crash, and will do it really fast under load, because of known or unknown reasons. That’s nothing you can really control, it’s because PHP is meant to die. The basic implementation, the core feature of the language, is to be suicidal, no matter what.

On the Inviqa techPortal today there's a new post talking about the New Relic monitoring service and what it has to offer PHP developers and their applications to help them manage things like performance and resources.

The performance of a web application plays a critical role in how an application is perceived by its users. It is important to measure it, identify the causes if it changes and react swiftly to any unexpected changes. This article describes an industry leading tool, New Relic, and how it can be used to monitor and improve your site performance. [...] New Relic is a real-time application monitoring service, providing various metrics about the performance of your production site, covering everything from application database queries through to the time it takes for the end-user to view a page.

They walk you through a "getting started" with the tool and how to get it running on your server - for PHP this means installing an "agent" extension and a local daemon for it to feed information back to. They then get into some of the data New Relic provides including application performance details, browser information, throughput and an Apdex score.

Simas Toleikis has a new post today looking at a method he's found for creating a simple daemon application in PHP. He gives you the basic outline of how it works (with a bit of code included) but not a specific example.

There is a special group of applications that require a different PHP script execution model. [...] All of [these special] applications need to be run in the background as daemons - something that PHP was never designed/supposed to be good at. The plain C language is a weapon of choice when it comes to writing a daemon implementation, but then again, if the application in question does not depend on high performance and concurrency - PHP can do the job quite well.

He talks about using the command line interface to run the scripts, creating the while loop to keep execution going and creating the non-blocking socket so that the script can accept new client connections. He also mentions using upstart to run the script in the background and the proctitle PECL extension to give the process a custom name in the process list. He also touches on log files and forking/parallel processing.

On the Re-Cycled Air blog Jack Slingerland has posted another in his "Dark Arts" series looking at some of the lesser used PHP features. This time he focuses in on daemonizing a process by forking it off into the background.

One of the many things you don’t often do with PHP (actually, I’m not sure you do this much with any language) is daemonize a process. A daemon is program that runs in the background (read more here). On Unix systems, processes are usually created by forking the init process and then manipulating the process to your liking. To create a daemon though, you need to get the init process to adopt your process. To do that, as soon as you fork the parent process, you kill the parent. Since you child process is parent-less, the init process generally adopts it. Once that happens, your process has been daemonized.

He uses the pcntl_fork function to spawn off the child process, detach it from a terminal window, create a ".pid" file so the system knows about it and then, of course, have the child script do something.

On his blog today Kevin Schroeder has the latest in a series of excerpts from his book "You Want to Do WHAT with PHP?" - a section of the chapter on daemons.

PHP is a language generally not suited for running daemons. That said, PHP can do it, and in certain circumstances does it sufficiently for the job. In this chapter we look at some of the things you need to know about to build a PHP-based daemon. This excerpt doesn't feature any code, but it does set the foundation for why I think PHP is fine for daemons in some circumstances.

The excerpt is mainly the first part of the chapter that just introduces the idea of daemons including some of the right and wrong uses, using the right tool for the job and how using PHP for a daemon can help with needs in a place where PHP might already be a norm.