The Laravel News site has a new tutorial posted showing how to speed up your PHP execution when developing with Docker by making use of the OPCache functionality.

If you’re on Docker for Mac or Docker for Windows, you might see some noticeable slowness and time to the first byte (TTFB) depending on your application’s setup. One of the most important things you can do to improve performance is enabling the OPCache module (regardless of the development environment). There are other things like volume caching (if possible), but OPcache is a win that you want in any environment you’re running PHP applications.

The tutorial starts by sharing a basic Opcache configuration, setting values for timestamp validation, memory consumption, and fast shutdown. These values are static and not very flexible so they change things up by making them able to be set as a part of the Docker build process. The post includes the changes you'll need to make to your Docker configuration to make this setup work in two ways: either copying the file in on build or making use of environment variables to set the configuration options at runtime.

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.

On his Medium site Olav van Schie shows you how to "make your Laravel app fly" with the help of OPcache. While OPcache isn't something that's specific to Laravel, he does include a package near the end that makes it easier to use it with the caching built into "artisan".

Every time you execute a PHP script, the script needs to be compiled to byte code. OPcache leverages a cache for this bytecode, so the next time the same script is requested, it doesn’t have to recompile it. This can save some precious execution time, and thus make your app faster (and maybe save some server costs).

He starts with a brief overview of OPcache and the main benefit it provides. He also shares some benchmarks he performed on a Digital Ocean server based on the results of performance testing the default Laravel "welcome" page. He then shows how to check and be sure it's installed and enabled on your PHP installation and some good default settings to configure in your php.ini. The post wraps up mentioning the package that helps integrate it with the Laravel application and the command required to clear out the OPcache on deploy.

In a new post to his site Mattias Geniar looks at an old security issue in PHP, opcache information leakage and how to mitigating the issue.

A very old security vulnerability has been fixed in PHP regarding the way it handles its OPCaches in environments where a single master process shares multiple PHP-FPM pools. This is the most common way to run PHP nowadays and might affect you, too.

He starts by talking about the vulnerability itself, that the PHP process doesn't validate the userid when fetching cached bytecode. This could result in information from other operations/scripts being exposed to other processes in a PHP-FPM pool. His solution? Upgrade PHP (the bug is fixed back in PHP 5.6.5) and set a few additional opcache ini settings to enforce the validation. Besides 5.6.29, it was also corrected in the PHP 7 releases (7.0.14 and 7.1.0). The post then talks about the potential exploit - an indirect local privilege escalation to root where the shared memory is read and access to outside information is possible.

In this post to his site Julien Pauli looks at the concept of "huge pages" and how it relates to some of the behind the scenes work done in PHP 7 to improve memory usage.

Memory paging is a way Operating Systems manage userland process memory. Each process memory access is virtual, and the OS together with the hardware MMU must translate that address into a physical address used to access the data in main memory (RAM).

Paging memory is dividing memory in chunks of fixed size, called pages. [...] Why use huge pages? The concept is easy. If we make the OS Kernel use bigger page sizes, that means that more data can be accessed into one single page. That also means that we'll suffer from less TLB miss, once the page translation is stored into the TLB, because one translation will now be valid for more data.

He briefly covers how some updated memory handling and opcode restructuring helps PHP 7 perform even better, especially when it comes to the OPCache handling. He talks about the changes made in the extension specifically to support the "huge pages" idea, complete with code examples (in C) of how this was accomplished.

On the SitePoint PHP blog there's a new tutorial posted helping you understand OpCache, the caching engine built into PHP versions 5.5 and above. This cache isn't designed to cache data or other content, though. An OpCache caches "opcodes" when a script is executed.

PHP in version 5.5 comes with a caching engine built-in – OpCache – which stores precompiled script bytecode in the memory. If you’re familiar with APC or Xcache, you will already know how such engines work. As each PHP script is being compiled at runtime, a part of the execution time gets used for transforming the human readable code into code that can be understood by the machine. A bytecode cache engine like OpCache, APC or Xcache does it only once – during the first execution of a specific PHP file. Then the precompiled script is being stored in memory, which should lead to performance boosts in your PHP applications.

The remainder of the article is a series of answers to some common questions about using the cache, what it will do for your applications and some tools to use for tuning and status updates:

• Is OpCache worth installing at all? What speed boost can I expect?
• I already use APC cache. Should I migrate to OpCache?
• How to check if OpCache is actually caching my files?
• Is there any framework-specific config that I should set?
• I keep my app config in a PHP file. Can I prevent it from being cached?
• How can I run both a development and a production environment on a single server where OpCache is enabled?

Simon Holywell has posted what he calls a "showdown" between HHVM, Zephir and PHP comparing various benchmarks (based on a Mandelbrot Set fractal).

Since its inception the slow running speed of PHP has been widely publicised and over the years there have been a number of improvements. [...] It has become more interesting recently however with three projects looking for improvements in different ways. The core has adopted the Zend OPcache for future versions of PHP, Facebook has been working on a just in time compiler called HipHop VM and the team that brought us Phalcon framework have created Zephir.

All of these projects have chosen to tackle the issue of PHP's speed via different avenues. It has therefore left one simple question - who's making the biggest improvements? Who's the fastest?

He briefly introduces the "contenders" for those not familiar with them and gets right into the benchmarking process. He shares the link to the tests he used and a few notes about the HHVM setup that could account for lower numbers. He shares his results in a few graphs or you can grab the CSV data yourself and parse it. The entire setup is also over on GitHub if you'd like to just check that out.

Davey Shafik has a new post to his site today sharing everything you need to know about opcode caches, the mechanism that's works "behind the scenes" to cache the execution of the opcode paths for later reuse.

Last year I wrote a talk called “Fast, Not Furious: How to Find and Fix Slow Code” - a performance talk covering profiling, memcache and some other stuff. As I often do - to hedge my bets = I stuck a few slides on the end “just in case” I ran through everything too quickly and needed to fill in time. These slides were on APC, the Alternative PHP Cache, and went just a little into tokens and how APC works under the hood. I really enjoyed presenting those 6 slides, and I’ve been wanting to expand on that topic ever since then. Well, after a few weeks of hard work, some input from some great people, including Sara Golemon, Elizabeth Smith and Julien Pauli, I’m so very happy to publish PHP Performance I: Everything You Need to Know About OpCode Caches.

The result is published over on the Engine Yard Developer Center and has been made into a 20 minute screencast (with original slides here). He covers what they are, which ones are out there, the common execution cycle and what happens when the opcodes are cached.