On the Symfony Finland site there's a post about a relatively new way to run PHP applications and how it's "growing up" to become a viable option: PHP-PM.

PHP-PM is a novel way of running PHP applications. Instead of creating an exotic high performance runtime for the PHP language, it takes an alternative route to mechanism of running PHP applications with existing runtimes.

This translates to real performance gains with existing complex applications, not just impressive theoretical benchmark results.

Instead of the usual complete bootstrap that normal PHP process goes through in its lifecycle, PHP-PM runs them as a continuous process, making for a huge boost in overall performance. The project has started gathering more momentum and is being worked on to make it a more credible platform for PHP applications.

From the humble beginnings the PHP-PM now has over 1700 stars on GitHub and a number of developers working on it. Great strides have been done since the early stages with the documentation and ease of use, but most importantly the platform now supports multiple frameworks: Symfony, Zend and Laravel.

Ole Markus has a new post to his blog looking at a technique for working with memcached and fetching data out of the store using a binary semaphore for better performance.

A typical document takes but a few hundred milliseconds to generate when a single request for the document enters the backend. The problem is that this is a highload website. In its current form, the backend serves hundreds of pages per second. This pretty much guarantees that the backend will concurrently receive cache miss on multiple languages and at the same time also receive cache miss on the pre-translated document.

Given that he wants the translated version to be the one that's always shared, a problem can come up when the cache request is "missed" and the document starts generating from multiple places. His fix for the situation is that only the first miss generates and all others see a lock on it and wait for it to be removed before successfully fetching the result. He provides code in a "LockedMemcached" class to help make it all more useful.

John Lim has written up an article for the Oracle Technology Network about creating high performance systems with Oracle's Real Application Clusters (RAC) and PHP.

Running a software application that is able to work reliably through hardware and software failures is incredibly hard. [...] In this article, I will cover the network, architecture and design of our RAC application. Then I will discuss the real-world experiences and problems we experienced.

He details their RAC setup - load balancers, application servers and their RAC servers - before working through the different technologies and how they're all installed and configured to work together most efficiently.

On the Ibuildings techPortal blog today there's a new article (a case study of sorts) on how to survive a plane crash. More specifically, a look at how the NU.nl news website handled the load as a result of the crash of a Turkish Airliner.

On February 25th, 2009, less than 90 days after the new infrastructure was rolled out, it was stress tested when a Turkish Airliner crashed at Schiphol. On that day the new site set a single day traffic record by serving up 21 million page views in a 24 hour time period, all without any noticeable slowdown and without having to bring additional hardware online to handle the additional load.

Their framework of choice, CodeIgniter, allowed then to create snippets of content - cached versions - that could be pulled and displayed without having to render them every single time. They looked into the Varnish project and a ATK-based CMS to piece it all back together.

Mike Naberezny has posted about some improvements that were made to the PHPUnit testing software lately (support for TestNG-style groupings) and how, with a few of his own suggestions it was made a bit more flexible.

At my company, we typically organize our test case classes into high-level groups such as unit and functional. Method-level group annotations are inconvenient for us because we'd need to annotate every method of every test case class.

He includes an example of their use - commenting a testing class and running it through the phpunit command line tool with a call to the testing group's name.

Mike Naberezny has posted about some improvements that were made to the PHPUnit testing software lately (support for TestNG-style groupings) and how, with a few of his own suggestions it was made a bit more flexible.

At my company, we typically organize our test case classes into high-level groups such as unit and functional. Method-level group annotations are inconvenient for us because we'd need to annotate every method of every test case class.

He includes an example of their use - commenting a testing class and running it through the phpunit command line tool with a call to the testing group's name.

In this new post, Justin Silverton shares a few helpful hints for creating high performance applications in PHP:

• use multi resultset queries to your database rather than many small ones
• page/object caching
• gzip compression
• tune your web server
• Don't save performance testing for the end of the project

Each of the items has explanation and links to more details on them (including links to three difference object caching applications - ion cube, alternative PHP cache, turck MMCache).

In this new post, Justin Silverton shares a few helpful hints for creating high performance applications in PHP:

• use multi resultset queries to your database rather than many small ones
• page/object caching
• gzip compression
• tune your web server
• Don't save performance testing for the end of the project

Each of the items has explanation and links to more details on them (including links to three difference object caching applications - ion cube, alternative PHP cache, turck MMCache).

On his blog today, Justin Silverton has posted this brief new tutorial covering the use of PEAR's cache_lite package.

Cache_lite is a php/pear caching module that is designed for high traffic sites. It is different than most caching systems because it has a built-in locking mechanism that will prevent cache corruption that can sometimes occur when there are a large amount of concurrent users trying to read and write to your cached data.

He wastes no time getting to the examples, showing first a very basic example of chacing/looking for a cache of your data. There's no installation HOWTO, but if you're familiar with the PEAR system, installation should be a simple matter.

On his blog today, Justin Silverton has posted this brief new tutorial covering the use of PEAR's cache_lite package.

Cache_lite is a php/pear caching module that is designed for high traffic sites. It is different than most caching systems because it has a built-in locking mechanism that will prevent cache corruption that can sometimes occur when there are a large amount of concurrent users trying to read and write to your cached data.

He wastes no time getting to the examples, showing first a very basic example of chacing/looking for a cache of your data. There's no installation HOWTO, but if you're familiar with the PEAR system, installation should be a simple matter.