On the TutsPlus.com site today they've posted a new tutorial spotlighting one of the components that makes up the Symfony framework, the Symfony Cache Component - and how you can use it to improve the performance of your applications.

Today, I'll show you the Symfony Cache component, an easy way to add caching to your PHP applications. This helps improve the overall performance of your application by reducing the page load time.

[...] In this article, we'll explore how you can unleash the power of the Symfony Cache component. As usual, we'll start with installation and configuration, and then we'll go on to explore a few real-world examples in the latter half of the article.

The tutorial starts with a few basic terms you'll need to be familiar with to use the component. From there it's straight into the installation and configuration of the component. Code is then included showing a more "real world" example of caching several different kinds of data, fetching it and setting expiration times. It then walks through each line of the code explaining how it works and more context about what's happening behind the scenes.

Christoph Rumpel has posted a guide for the Laravel users out there that have wanted to implement a Content Security Policy (CSP) in their application. A CSP helps to prevent cross-site scripting issues by locking down the images, scripts, resources, etc. that can be used in your application.

Caching is lovely, and the Content Security Policy is incredible. But when you put them together... Let me show you the problems I encountered, and how I fixed them.

He starts by describing the setup he was working with and improvements he was making (using the Spatie Laravel ResponseCache package to improve the performance of his site). As a part of the refactor he decided to implement a CSP but had an issue where the nonces on the included scripts didn't change like they did in development. To resolve the issue he created a middleware that takes the response and, after calling the other middleware, append the header to the response instance. Full code for the solution is included in the post.

Alison Gianotto has an article posted to her since basically answering the "now what?" question resulting from you running Composer as root on your system.

Composer is a PHP dependency manager that’s used in just about any modern PHP application, and it works similarly to how Bundler works for Ruby.

Even though Composer itself gives you a warning about not running it as root, lots of people disregard this warning and run it as root anyway. We run into this issue a lot on my open source asset management project, Snipe-IT, so I figured I’d write up how to fix this if you inadvertently (or advertently) ran composer as root.

She starts by describing the difference between "installing Composer as root" and "running the Composer install as root" (two very different things). She points out that, while Composer tries to prevent the second but permissions errors sometimes cause people to move forward as root anyway, despite the warning. She then shows how to fix the permissions issues so it can be run as a normal user, updating the files in .composer for the root account and re-running the install.

In a new post to the Facile.it Engineering Blog author Salvatore Cordiano wonders if it's all PHP OpCache's fault when it came to an issue they were seeing post-deploy.

Upon migrating to a new infrastructure we started experiencing cache issues after each deploy: as we refreshed pages that were updated by the new release, we didn’t see the right content for a very short period of time. Initially, we wrongly assumed that the cause of this issue was the PHP OPcache extension but, after our investigation, we understood that real path cache was the culprit.

He starts from the beginning (a good place to start) and gives some background on the application they were working with and what they were trying to correct. After they deployed the newly pushed version wouldn't show when the pages loaded for a little while. He covers the deployment process they use and the commands/scripts they use. They started wondering if it was somehow PHP's own Opcache functionality that was caching the pages and not releasing them right away. They made some updates to their deployment process to try to resolve this.

After some investigation, however, it was discovered that the realpath caching was at fault. It wasn't updating the cache to point to the newly released files. In order to correct the issue, they tinkered with the php.ini settings related to the cache to disable it when the code is pushed.

Sergey Zhuk has written up a tutorial showing you how to implement promise-based caching with ReactPHP, a continuation of a previous post.

In the previous article, we have already touched caching (when caching DNS records). It is an asynchronous promise-based Cache Component. The idea behind this component is to provide a promise-based CacheInterface and instead of waiting for a result to be retrieved from a cache the client code gets a promise. If there is a value in a cache the fulfilled with this value promise is returned. If there is no value by a specified key the rejected promise returns.

He starts by defining the caching interface and how it would look in use to set/get a cache value. He shows how to update this with a "done" handler to output the value when the get is complete. He continues on showing how to use a fallback handler: either "otherwise" or "then". He also shows how these can be chained together to make more complex operations. The post ends with an example of this caching component in action and links to other library that use the same ideas.

In this post to his Medium blog Pawel Mikolajczuk shares some helpful tips for getting the most performance out of your Twig output with some custom caching techniques.

In Superdesk Publisher we have implemented Mutlitenancy with possibility to have multiple themes (but one activated). To make process of switching, uploading and updating themes for tenant we had to came up with solution to clear cache only for one particular theme not the whole instance (with many organisations and tenants).

To achieve that we created custom Twig Cache class.

He then shares the code for the class, extending the base Twig filesystem caching, to work with the multi-tenant architecture. It ensures that the output from one account is completely separate from another, preventing concerns of the wrong data being shown to the wrong user. He also shows how to enable it in the application configuration (Symfony) and a custom "compiler pass" class to finish the integration.

In a new post to his site Rob Allen talks about how you can speed up the routing in your Slim framework based application using the route cache file.

When you have a lot of routes, that have parameters, consider using the router's cache file to speed up performance.

To do this, you set the routerCacheFile setting to a valid file name. The next time the app is run, then the file is created which contains an associative array with data that means that the router doesn't need to recompile the regular expressions that it uses.

He gives an example of how to enable the setting and makes the recommendation that it's only used in production. He includes a simple example that defines "25 groups, each with 4000 routes, each of which has a placeholder parameter with a constraint." The first run on a route responds in 2.7 seconds but, once the cache file is created, it drops down to just 263 milliseconds - a major improvement.

On the Zend Framework blog Enrico Zimuel has posted a tutorial showing you how to use middleware caching in Zend Expressive to help increase the overall performance of your application.

Performance is one of the key feature for web application. Using a middleware architecture makes it very simple to implement a caching system in PHP.

The general idea is to store the response output of a URL in a file (or in memory, using memcached) and use it for subsequent requests. In this way we can bypass the execution of the previous middlewares starting from the second request.

Of course, this technique can only be applied for static contents, that does not require update for each HTTP request.

He shows how to implement the "cachable" middleware, starting with a version that caches the return content based on the URL requested. He then shows how to configure the caching system to specify settings like path, lifetime and the enabled/disabled state. This is stored as a PHP configuration where the autoloader can get to it and the class as a dependency on the middleware itself.

On the Laravel News site there's a quick tutorial posted showing you how to use Laravel's query cache with query params to help increase the performance of your application by caching query responses.

Laravel provides a very intuitive and useful means of caching the responses of your projects, whatever your project is (RESTful API, Web Platform, etc.). In general, Laravel can store in the cache system whatever data you send (HTML, JSON, collections, Eloquent instances, and similar) accordingly with a provided expiration time.

[...] The question here is “How does Laravel determine when to store data?”

They give an example of saving a "remember" key value to the cache manually using the "remember" method on the Cache facade. He then talks about what happens internally when the "remember" method is called to know if the data was previously cached. It then moves into the caching of data based on URL values and how query params would confuse things and not provide much benefit to the caching. Thanks to some internal handling the caching ignores the query params and returns the same data as before. This is an issue if you want the updated data but is relatively easily solved with a bit of code to sort the params and normalize the URL being used as the "remember" key.

The Laravel News site has a quick new post about some routing improvements that are coming in the next larger release of the framework , Laravel v5.4:

As Laravel 5.4 development continues, two new improvements are coming to your routes, better route caching for large applications and fluently registering routes.

The route caching updates will help performance with larger applications, reducing the parsing time required to locate and push a request to the right location. The "fluent" route improvements basically allow for the definition of some things, like middleware or route names, as a part of the route definition rather than after the fact. Examples of this are included in the post.