Chris Jones has a new post to his Oracle blog today talking about the new "opcode" opcode caching that's going to be built into future PHP versions This is the implementation of the Zend Optimizer+ opcode caching in a native language interface. The latest PHP 5.5 snapshots have it included.

The new "opcache" can be seen as substitute for the venerable APC cache, the maintenance of which had become an issue. Note: although opcache is now readily available, there is currently nothing preventing you from using any available (working!) opcode cache in PHP 5.5.

He gives you a quick guide to getting this new opcode caching enabled and compiled into a shiny new download of the PHP 5.5.x branch. You'll need a special command line flag on the compile and to update your php.ini to load the needed shares module. You can also use it if you're on PHP 5.2 or higher either by compiling this source or using this PECL extension.

On PHPMaster.com Timothy Boronczyk has written up a tutorial about using the Slim microframework as a sort of "middleware" in your application - a wrapper around other functionality with an easier to use interface.

Slim is a microframework that offers routing capabilities for easily creating small PHP applications. But an interesting, and powerful, feature is its concept of Middleware. [...] I've found middleware to be an eloquent solution for implementing various filter-like services in a Slim app, such as authentication and caching. In this article I'll explain how middleware works and share with you a simple cache example that highlights how you can implement your own custom middleware.

He talks about what "middleware" is (complete with illustration) and how Slim can be used as a layer in the middleware stack. His example is a caching layer, based on Slim, that takes a request, checks the cache for it and returns it if it exists. If not, it saves the content to a database. He also includes code examples of how to use the "add" method to introduce your middleware libraries into the Slim application.

If you'd like more examples, the Slim project has several middleware examples provided in their "extras" github repository.

In this new post to his site Kevin Schroeder thinks out loud and wonders if an idea of his is "a dumb idea" to be included into the PHP core - engine state caching.

I was consulting and I would see significant server resources consumed by bootstrapping the apps. Loading config files, loading dependent classes, setting up dependencies, initializing ACL's, and the list goes on and on. One of the ways to negate the effect would be to cache a bootstrap object and then pull that object from the cache at the start of the request. However, the problem is that unserialization can actually end up taking more time than the bootstrap process itself.

He wonders if, after the initial bootstrapping happened, a method could be called (his example is "init_engine_state") that would cache the Zend Engine's current state and pass that to a callback function. This would cache everything - objects, variables, classes, etc - all pre-interpreted into memory and make them easy to reuse on future executions. What do you think? Share your thoughts in the comments of the post.

James Fuller has posted a guide to scaling your web application using the nginx web server, memcached, PHP-FPM and APC caching.

We sell an educational product that serves a predictable 15,000 requests per minute for 10+ hours/day, every day. Instead of Apache, we use nginx with PHP-FPM to handle this traffic. This is becoming a very popular setup for many companies with non-trivial traffic, but I have also found success with it in my small 256MB Ram VPS. For various reasons, nginx does a better job with memory and concurrent connection handling than Apache. In this post, I want to talk about some of the reasons you might want to go with this setup.

He talks about some of the efficiency gains that memcache and nginx can give you pretty easily and some of the common uses for nginx, including using it as a reverse proxy. He talks some about Apache's typical request handling and shows the difference between that and how nginx does its "never block, finish fast" handling. He fits in the other pieces - PHP-FPM, memcached and APC - showing how each of them offers their own types of performance gains for different areas of the application.

Michael Nitschinger has written up a new post comparing a few different methods for serializing or translating objects to store them in a cache. In it, he compares the PHP serializer, the igbinary extension and translation to JSON.

Storing PHP objects (or simpler data types like arrays) in caches always requires some kind of transformation. You need a way of encoding/decoding data so that it can be stored and loaded properly. In most languages, this process is known as object serialization. PHP provides a mechanism for this out of the box, but in this article we'll also look at igbinary as a drop-in replacement for the default serializer. We also compare the results to object transcoding based on JSON, which is not really an object serialization mechanism but commonly used as a data chache structure which has its own benefits and drawbacks.

He goes through each of the three technologies and includes a snippet of code showing how they'd work in object translation. He also talks about things like the size of the result and the performance of each when the results are looped over. Based on the results of some of his "microbenchmarking" of each of the methods, igbinary came out on top, even faster than PHP's own serialize/unserialize.

On PHPMaster.com today there's a new tutorial that can help you increase the performance of your application relatively painlessly with the help of the Varnish proxy tool. The article helps you get started.

Varnish is a reverse proxy server; it sits in front of your web server and serves content from your server and no one else's. Reverse proxy servers are tightly coupled to the web server and can act on messages received from it. [...] Simply put, Varnish does one thing: serve web content super fast.

You'll need command line access to the machine (as well as permissions to install the software) but getting it installed is a simple "apt-get" away. There's a bit of configuration to set up to get it up and working, but it's only a few lines...and examples are included in the tutorial. They get into some of the more advanced configuration options too, like the time-to-live and changing the port it listens on. Varnish isn't just for PHP applications either - it can be used effectively for any kind of web application as it's just a proxy layer that sits on top and waits for requests.

Michael Nitschinger has a new post to his site today showing how you can cache the entities you've created with Doctrine using Couchbase as a simple caching tool.

As part of our ongoing efforts to make Couchbase more integrated with frameworks and libraries, we added caching support for the Doctrine ORM. [...] Caching can either be used standalone (through the API provided by doctrine/common) or integrated with the ORM functionality. We'll look at both variants through simple examples, a good documentation can also be found here. Note that at the time of writing, the CouchbaseCache is not mentioned as a caching driver because the documentation still needs to be updated.

He walks you through the steps to get everything you need installed, both through Composer and the Couchbase extension so your PHP installation will support it. He includes sample code that sets up the cache and shows how to check it to see if a key exists. With this base in place, he expands it out to working with the Doctrine ORM. He shows how to create a sample "Person" entity, inject it into the entity manager and perform a query with the Result Cache to locate the object.

If you're considering using Zend Server in your development, you might find this new post from Matthew Weier O'Phinney interesting. It talks about a handy feature of the tool and how it can help with the performance of a Zend Framework 2-based application.

Zend Server has a very cool Page Caching feature. Basically, you can provide URLs or URL regular expressions, and tell Zend Server to provide full-page caching of those pages. This can provide a tremendous performance boost, without needing to change anything in your application structure; simply enable it for a set of pages, and sit back and relax. [...] However, this feature is not entirely straight-forward when using a framework that provides its own routing, such as ZF2. The reason is because it assumes by default that each match maps to a specific file on the filesystem, and prepares the caching based on the actual file it hits.

Since configuration is mostly done through Server's web interface, this could be a problem. Thankfully, he shows you another setting that allows you to cache multiple versions of pages based on parameters you define. Using this and a setting of "_SERVER" with a value of "[REQUEST_URI]" you should be good to go.

In this new post to DZone.com, Giorgio Sironi shares a few helpful hints on using the APC tool to help improve the performance of your web applications.

APC (Alternative PHP Cache) is one of the orthogonal tools you can use to speed up the execution of PHP code. This article explains from scratch the correct use of APC's system cache (not touching the user cache, which is just a standard key/value map). APC has also other features like upload progress support, but the system cache is its main features and has such a little footprint on your code that you should throw an apc.php file to everyone picking on you for writing strings in single or double quotes.

He describes what the APC cache does for you (both on a lower, opcode and a higher, performance levels) and how it relates to the shared processes a web server uses. He finishes off the post with a quick guide to getting it installed and working ("pecl install") and some of the common settings to tweak to get the most of the functionality.

The Agile Toolkit blog has a new post today that looks at speed in PHP frameworks the their relative speed (no, there's no benchmarks here).

This question is often asked, but is never answered properly. So how to measure framework speed? Let me also explain why "scalability" is more important than general "performance". [...] This along with a general overheads of the framework greatly contributes to the "slowness" of your project. So how can framework contribute to performance of your project?

They touch a few different ways that frameworks can help execute things a bit faster like:

• Make Fewer SQL Queries
• Selective render
• Parallelization
• Overheads
• Caching