Derick Rethans has shared a post on his site with an experience he had with a mystery of missing breakpoints and some issues he commonly is asked about regarding Xdebug's breakpoint functionality.

Occasionally I see people mentioned that Xdebug does not stop at certain breakpoints. This tends to relate to multi-line if conditions, or if/else conditions without braces ({ and }).

f you set a breakpoint at either line 7, 11, or 12, you'll find that these are ignored. But why is that?

To help explain, he uses the vld tool to show the opcode behind the language's processing. In its results you can see that a EXT_STMT code is missing for the lines where the breakpoints were set. Xdebug doesn't see the marker it's expecting so the breakpoint isn't recognized and execution isn't halted as expected. He offers some suggestions you can use of other tools and functions to make sure the location you've selected can actually accommodate a breakpoint.

Joe Watkins has a post on his site sharing a project he has been working on to create a debugger for PHP applications that can be installed easily and understood by those already having knowledge of PHP.

We already have several options for debugging code within the PHP ecosystem. XDebug is extremely mature software, and phpdbg has been slowly gaining traction also, if for no other reason than it's very fast to collect code coverage compared to XDebug.

[...] Debugging is a necessary part of writing code; If you disagree with this statement, then I don't know what you are talking about. [...] Using a debugger is like having an army of nano bots at your disposal, each one trained exquisitely in a top nano-bot-training-camp, they live to kill cockroaches, some of them also have mean looking tattoos, chew tobacco, and spit on the ground at the start of every sentence ...

He goes on to talk about why he made the choice to write the debugger with a PHP interface. He then gets into some of the specifics of debugging needs and links to the krakjoe/inspector repository for the tool. The README has more information about the interface and functionality than the blog post does, so if you're interested to read more, head over there.

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.

The Tideways.io site has posted a tutorial showing you how to "avoid the thundering herd" of incoming requests to your application using a file-based PHP 7 opcode cache to reduce load and increase performance on your site.

In the last blog post about Fine-Tuning Opcache Configuration I mentioned the thundering herd problem that affects Opcache during cache restarts. When Opcache is restarted, either automatically or manually, all current users will attempt to regenerate the cache entries. Under load this can lead to a burst in CPU usage and significantly slower requests.

[...] In Rasmus talk at FrOsCon 2015 (Video at 12:30, Slides), he showed the persistent secondary file-based cache Opcache gets in PHP 7. It can read the generated opcodes from disk instead of having to recompile the code after cache restart. This happens only when the compiled opcaches are not found in shared memory.

They talk about the benefits that this caching can provide, not only to web-based applications but also to command line scripts. There's a mention of possible security issues if an attacker is able to read/write to the cache files (but permissions can help that). The post ends with how to install it on your own PHP 7 instance, using the --enable-opcache-file flag on compilation.

The SitePoint PHP blog has posted three tips on caching that can help speed up your application from the processing level up. The article shares tips on using opcode caching for faster processing, etags for web request caching and query caching on the data side.

In this article, we will be looking at some of the common caching techniques in PHP: Opcache, Expires Headers and Query Caching in MySQL. We’ll look at additional approaches in part 2.

He starts with an introduction to the request lifecycle of a typical request made to a PHP-based application, from the fetching of a file to the actual execution. This lays the groundwork for the first kind of caching: opcodes for caching execution results. He helps you get that enabled and configured and shows how to determine how much it's actually helping. Following this he talks about the "expires" headers you can send from Apache, telling the browser exactly when it needs to fetch new versions of things like CSS, image or Javascript files. Finally he touches on MySQL query caching, storing the already parsed version of a query on the server with results in a cache for faster polling on repeated requests.

The Tideways.io blog has posted a set of four macro-optimizations you can do to help improve the overall performance of your application. Note the "macro" here, not "micro", so these are larger, more platform-level changes.

This blog post describes four macro-optimizations for PHP applications that are essential to consider before investigating other possible optimizations. [...] While its fun chasing after small micro optimizations, often it is debatable if the developer time is well spent. After all I/O is the more important bottleneck in almost every application. [...] But its much more efficient to fix the big issues first. The changes I present in this post can be done quickly and their gains can be massive.

The four suggestions he makes cover different areas of a standard application:

• Upgrade PHP to a recent version
• Use accelerator such as APC or OPCache
• Close Session for Writes
• Don't run XDebug in Production

Each tip comes with a bit of background on why it's a good idea and some have links to other resources supporting the change or update proposed.

Julien Pauli has a new post today sharing an interesting function optimization he found using the Blackfire execution profiler.

This blog post is a technical explanation of a PHP optimization found with BlackFire profiler into a PHP script. The related post is located here : http://blog.blackfire.io/owncloud.html

He found that a replacement of a call to strlen with an isset optimized the script by about 20%. It's not typical though, he explains. He points out that the optimization worked so well because the call was part of a loop. He gets into some of the "under the covers" details of why this speed boost happens and even includes the op code output showing the difference. He then starts getting deep into the internal code for PHP and walks through each step made in the evaluation of a string's length. He finishes the post looking at isset (not technically a function) and how it handles its data checking. He also includes information about opcode caching and how to best maximize its impact.

Derick Rethans has posted the first in a series focusing on the Xdebug tool and the code coverage functionality it can provide via PHPUnit's testing. In this first post he catches the reader up on the current state of things and what all the Xdebug tool can do.

Since ages Xdebug has provided code coverage support for PHPUnit, a way to show which lines are covered by your test cases. But I never really wrote about how it works. A recently filed bug prompted me to write this post, as well as a follow up post on Code Coverage's future.

He starts off with the early days of Xdebug, how it hooked into the Zend Engine (that powers a lot of PHP behind the scenes) and when it was triggered. This came with its own set of problems so Xdebug was updated to overload some opcodes. He talks about how it can calculate the unused lines and determines which lines can be covered in the code coverage results. He provides some example code showing the execution of the coverage report on a simple function and try/catch handler, complete with the HTML output of the results.

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?

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.