Code coverage tells you how much of your code base is actually being tested by your unit tests. It's a very useful feature, but sadly, it slows down PHP's execution quite a lot. One part of this slowdown is the overhead to record the information internally, but another part is because I have to overload lots of opcodes. (Opcodes are PHP's internal execution units, similar to assembler instructions) They are always overloaded even if code coverage is not used, because it's only safe to overload them for the whole request.

These changes were from a combination of contributions from Taavi Burns and a new ini setting that will allow you to enable or disable the code coverage in XDebug. Benchmarking shows a good amount of time reduction in coverage runs - dropping anywhere from a few seconds to over a minute. He also mentions the idea of "modes", shortcuts to predefined settings for different types of reporting (like "profiling" or "tracing").

A few weeks ago I wrote a post that showed how to improve the performance of PHP applications on Windows by using the IIS output caching module. Using the output caching module can have significant positive impact on application performance since pages are served from cache without executing any PHP code. However, this very strength can also be a drawback depending on how your application is built. Because entire pages are cached, using output caching may not be ideal for pages that have multiple data sources.

He points to the Wincache extension as an alternative to the full-page caching with it's built-in opcode caching (you get for "free" just by installing). He mentions this and a few other features that come with it like the ability to cache to a file and to normalize file paths for more efficient seeking of files. He also focuses on partial caching with a specific example of caching user data for use through out the application. A bit of code and some screenshots are included to show the performance boost this can give.

dding APC to an application usually results in improved application response times, reduced server load and happier users. In this article, I'll introduce you to APC, guiding you through the process of installing and configuring it and showing you a few examples of how it works. I'll also walk you through the APC administrator interface, which lets you view APC performance in real time, and show you how you can use it with the Zend Framework

He shows you every step of the way - installation, configuration (complete with some screenshots) and the web-based interface you can enable to see the statistics about how the cache's performance is and what requests it's been handling. He mentions other abilities APC has like array and object caching, caching closures and finally a real-world example of using it to cache the results of a Twitter search request (in a Zend Framework environment).

PHP is great for writing quick dynamic stuff for your website. Just a couple of lines of code can be written in 2 mins to insert or retrieve data from db. But with ease there is also some pain… the downside is that each request for a dynamic page can trigger multiple db queries, processing of output, and finally formatting to display on browser. This process can eventually be slow on larger sites or slower servers.

There's lots of options here for all different levels of the code - opcode caching to speed up repetitive operations, data caching at the PHP layer, caching plugins and template caching.

Recently I've been working on some new functionality to visualise all the code paths that make up each function. These new routines sit on top of the routines that do dead code analysis. These new routines sit on top of the routines that do dead code analysis. Every branch instruction (such as if, but also for and foreach) is analysed and a list of branches is created. [...] Once all the branches and their links are found, another algorithm runs to figure out which paths can be created out of all the branches.

He illustrates with a few examples, showing both the command that was executed and the resulting output with the new path information of a simple test file using a "for" loop and an "if/else" conditional.

The [WinCache] documentation makes no mention of Apache, only IIS. I decided to give it a try, and to my amazement, WinCache worked in Apache on Windows. After that I decided to compare the performance of WinCache with the other available options for Windows+Apache.

He defines his testing environment - hardware, software and the different opcode caching tools - and includes his testing technique. His results, measured in requests per second, are interesting but show that, for his configuration, the WinCache tool's performance topped the others on Windows.

As PHP extends its reach further into corporate networks, IT managers have yet another technology that they have to understand so that they can properly deploy. In many situations, PHP code is being developed that - running on its own - creates a bad user experience because of the nature of the language. [...] Much of this delay, and the user unhappiness that always accompanies it, can be mitigated with the proper opcode caching solution. The list in this article was compiled to help managers understand what their options they have. These are the most popular or recent PHP opcode caching solutions.

He lists three of the more popular choices - the Alternative PHP Cachie, Zend Optimizer+ and the WinCache - touching briefly on what each has to offer.

"PHP tokens and opcodes" - When a PHP script is executed it goes through a number of processes, before the final result is displayed. These processes are namely: Lexing, Parsing, Compiling and Executing. In this blog post, I will walk you through all these processes with a sample example. In the end I will list some useful PHP extensions, which can be used to analyze results of every intermediate process.

He touches on the steps the average PHP script takes in its processing - lexing, parsing/compiling and the actual execution of the opcodes. The tokenizer, parsekit and VLD (Vulcan Logic Disassembler) extensions can help you get down into the nuts and bolts of the language and the engine that makes it work.

During the first pass, it will find out to which opcode it needs to jump in the jump instructions. However, the PHP engine (and Xdebug) expects a memory address to jump to while executing your script. In the second pass, the compiler will then go over the generated opcodes and calculate the memory address to jump to from the jumps to opcode numbers.

Because of the way that XDebug was handling the checks (with the user-defined error handler) and how the opcodes inside of PHP are handled, the user-defined handler happened in between the first and second phases and the latter run couldn't find the resources it was looking for, thus the crash.

After one particularly frustrating day [looking at how the Zend engine works] I asked a colleague (Andy Wharmby) about the issue I was looking at. Then a miracle happened - he'd not only looked at it but had documented it (and many other things) in a set of charts.

She has linked to the charts (Open Office format) for the results of some tests her friend had already run. They're a bit out of date and some parts might be inaccurate, but they're still a good start.