There's several ways to run PHP on various webservers out there and in a tutorial from the CloudWays blog they focus on one: using PHP-FPM and the performance gain it can give.

Speed matters. Our engineers are always looking at ways on improving the stack. One of the major objectives of our stack integrations is to improve the speed of the overall processes of our stack.

Keeping up with this practice, in a bid to increase speed of aspects of Managed Cloud Hosting coupled with constant improvements based on users feedback, Cloudways has now integrated PHP-FPM in all its servers. Owing to this integration, applications hosted on Cloudways servers are now going to perform up to 3x faster.

The post starts with a look at why to choose PHP-FPM and shares some benchmarks of it in use versus the more typical mod_php shared module. It then gets into the implementation steps, linking to a step-by-step guide on how to implement it.

Following up from his previous post about setting up Docker running PHP-FPM and Nginx on Windows 10, Pascal Landau has published the second part of the series taking things a step further and introducing (and integrating) PhpStorm and Xdebug for local development debugging.

In the second part of this tutorial series on developing PHP on Docker we're taking a good hard look at PhpStorm, Xdebug and how to run and debug scripts from within PhpStorm on Docker.

[...] The setup that I am going to use is for demonstration purposes only! I do not recommend that you use it "as is" as your development setup. [...] There will be a another part of this series that will deal with all of those (and some more common) problems and aims at providing a consistent development environment for all developers in a team (regardless of the OS they are using).

He then walks through the process from setup through actual script debugging:

• setting up the Docker containers/configuration
• allowing the PHP container to connect over port 2375
• running a PHP script on this container
• building a "workspace" container for Xdebug

For each step he provides the configuration changes needed, commands and screenshots of the settings panels to ensure its easy to follow along.

On the Websec.io site a new tutorial has been posted (a sort of continuation from this previous article) showing how to keep secrets safe in a PHP and Docker environment without too much overhead.

In a previous post I covered one method you can use to secure the credentials in your PHP application. In that article I provided an example specific to the use of Apache and its envvars handling to read in values and pass them along to the waiting PHP process as $_ENV variables. This in combination with the psecio/secure_dotenv library allowed you to pass along an encryption key that could be used to decrypt values from the application's .env file.

While this works for a flat Apache and PHP environment, the world has moved beyond that basic setup and has moved to using another popular environment building tool: Docker. [...] So, if we move forward with current technology, we need a way to secure our credentials in a Docker-based environment that makes use of PHP-FPM and Nginx. Fortunately there's a relatively simple way to handle this with just a few configuration changes.

The tutorial starts with an overview of what technologies are involved in the environment (Docker, PHP-FPM, Nginx and Vault) and some of the options for storing secrets with Docker. It then gets into the configuration files needed to create the environment: a Docker Composer configuration, the Nginx server definition, the PHP-FPM settings and the .env file that contains the secrets. Using these pieces and some special configuration directives, the secrets are injected into Docker when the containers are built and storing them in-memory rather that on disk.

On his site Pascal Landau has posted a complete guide to setting up a Docker-based PHP environment on Windows 10 using Nginx and PHP-FPM.

You probably heard from the new kid around the block called "Docker"? You are a PHP developer and would like to get into that, but you didn't have the time to look into it, yet? Then this tutorial is for you!

[...] This is the first part of a (probably) multi-part series on Docker. The next part will explain how to set up PHP in Docker containers in order to work nicely with PHPStorm when using XDebug.

He starts with a brief overview of why he chose to use Docker and the transition from Vagrant. He then breaks up the tutorial into several different sections, one for each area of the environment:

• setting up Docker
• creating the PHP CLI container
• building the web container (PHP-FPM and Nginx)

He "brings it all together", sharing a docker-compose configuration file that sets up all of the services and configurations in one shot. The tutorial comes complete with screenshots and all command line calls to get your environment up and running quickly.

Hayden James has a post on his site sharing a method he's found for getting better performance out of PHP-FPM with the help of a configuration change. In this tutorial he shows how to use the pm static setting to squeeze the best performance out of your web server.

Lets take a very quick look at how best to setup PHP-FPM for high throughput, low latency and a more stable use of CPU and memory. By default, most setups have PHP-FPM’s PM (process manager) string set to dynamic and there’s also the common advice to use ondemand if you suffer from available memory issues.

He starts by defining the three "pm" settings and what they do: dynamic, ondemand and static. He then talks some about how the PHP-FPM process manager is similar to CPUFreq Governor and the settings it allows. Finally he gets into talking about the "pm static" handling, how it relates to available memory and when it makes more sense to use "dynamic" over "static".

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.

In a follow up to his previous article about high performance PHP with React's help, Marc Schmidt has returned with a follow up post two years after the fact with some updates and additional information.

This is a follow up article on “Bring High Performance Into Your PHP App”, which went quiet viral with over 100k visits. This does not only show that many people still struggle with PHP and its performance, but also that people are highly interested in a solution to this kind of issues. PHP-PM could be one solution. But first things first. Over two years later since my blog post about high-performance things have changed dramatically.

[...] When I hacked together some lines of code back then in 2013 I never though that this kind of application style would ever succeed in the PHP world. [...] However, things have changed there as well.

He talks about some of the advancements that have been made since his previous post including PHP 7, improvements in PHP-FM and the HttpKernel component of the Symfony framework. Along the lines of bringing even more performance to PHP applications with React, they created an adapter to link the two. The post covers some of the currently open issues, the "good things" about it and some of the design issues to keep in mind when using it. He ends the post talking about where the PHP-PM project is now and some of the benchmarks about performance between PHP-PM and PHP-FPM.

Loïc Faugeron has continued his series about speeding up Symfony applications and getting the best overall performance you can. In this new post he gets into more detail about tuning a Nginx web server (with PHP-FPM) and the web server's own caching features.

HTTP frameworks, such as Symfony, allow us to build applications that have the potential to achieve Super Speed.

We've already seen a first way to do so (by turning it into a HTTP server), another way would be to put a reverse proxy in front of it. In this article we'll take a Symfony application and demonstrate how to do so using nginx.

He starts by helping you get Nginx and PHP-FPM all set up and running on a Unix-based system (installed via apt-get). He provides a simple configuration including the user to run as and a virtual host for the application. There's a few command line checks to ensure it's working correctly and a bit of benchmarking as a baseline for the performance testing later. He then gets to the caching functionality and gives some of the basics on how it works inside of Nginx itself. He includes a basic caching configuration (caching to files) and adding this to the already created virtual host. Finally he includes sample Symfony code to send the "Cache-Control" header with every request and runs the benchmarks again (resulting in about 140x faster than without the cache).

Vincent Composieux has put together a new tutorial showing you how to get a Symfony2 application up and running inside of a Docker virtual machine for development and testing.

Why boot a full virtual machine when you can only run Docker containers of what you need to develop your Symfony applications ? This is one question asked by Jeremy Derusse at his "Docker dans le développement l'intégration continue" talk during Symfony Live Paris 2015. Those slides are really interesting, I invite you to take a look. They demonstrate the power of Docker and docker-compose but are waiting for practice in order to well understand. So I enjoyed a rainy week-end for further study!

He then outlines the components needed for a simple Symfony2 application: Nginx, PHP (well, PHP-FPM), MySQL and, of course, the code for the application. He includes the full contents for the "docker-compose.yml" configuration file to generate this Docker instance. He walks through each of the components it requires and talks about what they contain and how to define each of them as an image. Following this, he creates the containers with a "docker build" and brings it all up and working with one "docker up" command. He also includes a few other helpful commands for getting memory/CPU usage as well as removing all containers and images with a single command.

On DZone.com today there's a post covering the different kinds of handlers that can execute PHP - those pieces of code that work with the web servers we use every day to interpret and execute PHP code.

PHP Handlers? mod_php? FPM? How do we make sense of the inner workings of PHP outside of our lines of code? We know we can run PHP on the server to build web applications swiftly, but how can we optimize our environment and configurations to reach maximum scale? We know that PHP has its drawbacks for not being asynchronous or event-driven, which is all the more reason to ensure maximum optimization. The impact of your server environment on your PHP application performance can be more than you think you can afford. A careful examination of your PHP ecosystem will help you avoid suffering performance loss in areas you can otherwise solve for easily.

They provide a brief summary of what PHP handers, well, handle and where they fit in the overall architecture of execution. They then get into the details on some of them:

• CGI – mod_cgi
• suPHP – mod_suphp
• DSO – mod_php
• FastCGI – mod_fcgid
• FPM (FastCGI Process Manager) – php-fpm

Included in each is an overview of how it works and some of the main advantages (and disadvantages) of their use. He also mentions two of the most popular web servers that work with these handlers: Apache and Nginx.