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.

On the Toptal.com blog there's a recent post about true dependency injection with Symfony between components in your application and only using the dependency injection container for its intended purpose.

Symfony2, a high performance PHP framework, uses Dependency Injection Container pattern where components provide a dependency injection interface for the DI-container. This allows each component to not care about other dependencies. [...] But this means DI-container can be used as a Service Locator.

[...] In this article we will try to build a Symfony2 application without implementing Service Locator pattern. We will follow one simple rule: only DI-container builder can know about DI-container.

They start off by talking about the structure of the dependency injection container and how it relates to the three main types: controller, method and property injections. He then starts in on creating the sample project and requiring only the Symfony DI, configuration and Yaml components. He then creates a ContainerBuilder class and sets up the HttpKernel functionality to pull the response from the container. He then makes a simple controller with a default action that just responds with text. With this working he updates it to pull in an input variable. He then makes updates to the application with changes to the route handing, templating (Twig), Doctrine (database) and tag handling.

In a post on the SitePoint PHP blog author Daniel Sipos takes you on a trip through the Drupal 8 execution structure, from request to response, in the internals of the tool.

In the first article on Drupal 8 module development we looked a bit at the routing aspect of this process. We’ve seen that creating pages with paths is now a matter of declaring routes that match up with controllers. The latter, as we’ve seen, can return a render array that gets interpreted into markup and displayed in the main content area of that page. However, did you know that under the hood, Drupal actually transforms that array into a Response object according to the dictates of Symfony’s HTTPKernelInterface?

In this article, I would like us to go deeper into the internals of Drupal 8 (and Symfony2) and look at what actually happens (and can happen) from the moment a request is made by a user to the one in which they see something returned in response.

He starts at the initial point of the request, the front controller, and talks about the creation of the Request instance and it's handling by the HTTPKernel. He moves into the kernel and talks about the events that are triggered during execution and provides an illustration of the flow of the request all the way through to the response. He then "goes deeper" into looking at render arrays and the HTMLRenderer handling to manage the output of the page on the Drupal side.

On the ServerGrove blog today they've posted the second in their series focusing on individual components of the Symfony2 framework. In this new post they look at the HttpKernel component, another of the foundational blocks of the framework.

In the second post of the Symfony2 components series we are going to talk about the HttpKernel component. If the HttpFoundation component provided the building blocks of the HTTP protocol, the HttpKernel component makes use of them to define an abstract process for converting a Request into a Response.

The post looks at the HttpKernelInterface, the "front door" to the component that takes in a Request object and makes its contents accessible. Also included is a list of some of the configuration options that can be used to alter its behavior, all based on events that fire during execution (the kernel is driven by events). There's also an example included of using the StackPHP middleware as decorators on the kernel.

Fabien Potencier has new post post to the Symfony Blog today talking about a big update to the Symfony framework, the introduction of a new "fragment sub-framework". This framework (now a part of the HttpKernel) allows the handling of requests based on a few different strategies.

About a month ago, I merged a complete refactoring of the sub-requests management of Symfony. In fact, I created a whole new sub-framework to handle the rendering of resource fragments via different strategies. [...] Besides classical master requests, the HttpKernel component is now able to handle sub-requests. Let's me sum up the different strategies that are available: internal sub-requests, ESIs, HIncludes, and SSIs (in 2.3).

He talks some about each strategy and what situations they're best suited for and some sample code that shows the use of the "standalone" and "strategy" parameters. There's also new methods you can call (like "render_esi" or "render_hinclude") to work with the new features as well.

On his site Fabien Potencier has posted about a feature added to Silex to help make debugging the flow of your application "more fun" - the Symfony web profiler.

One of the big advantages of both Symfony and Silex is that they are based on the Symfony HttpKernel component. [...] But handling HTTP requests with the Symfony HttpKernel also gives you a lot of free and optional features like a built-in reverse proxy written in PHP, easy handling of ESI and Hincludes (via the Fragment sub-framework), or the gorgeous Symfony web profiler.

The profiler provides information on which components were accessed, their memory consumption and how long they took to execute. The integration happens via the WebProfiler provider for Silex and is already integrated into the Silex skeleton base application.