If you've ever been trying to squeeze more out of hardware you must have come across Nginx (engine x). Nginx usually appears in context of PHP-FPM (FastCGI Process Manager) and APC (Alternative PHP Cache). This setup is often pitched to be the ultimate combo for a web server but what that really means? How much faster a PHP application is going to be on a different web server? I had to check it and the answer as often is - that depends.

He ran the tests on an Amazone EC2 instance and optimized the server to ensure that there was a little interference as possible. The used the Zend Optimizer Plus opcode cache and PHP 5.4 and set the logs to go to memory instead of disk. Graphs included in the post show the results of the benchmarking of each application, with the differences (in most cases) not being that wide of a gap.

There isn't big difference between Apache2 and Nginx in PHP context. Yes, Nginx can be much faster when delivering static content but it won't speed up PHP execution. Running a PHP script seams to be so CPU challenging task that it completely eclipse any gain from a web server.

Since its inception, Zend Framework 1 has used Subversion for versioning. However, as we approach its end-of-life (which will occur 12-18 months from the time this post is written), and as our experience with ZF2 processes becomes more familiar, we -- the Zend team and the Community Review team -- feel that we can better support ZF1 via GitHub. As such, we will be migrating the ZF1 Subversion repository to GitHub this week. Please read on for details!

The post details the steps that'll be taken during the process including the changing of the location of the "master" branch (and how to change svn to point to it) and the updates to the integration of the Dojo libraries. They also talk some about the "extras" repository and how things will work with the Issue Tracker and pull requests in the future.

The repository and issues migration is the first step in a series of planned migrations. We also plan to eventually migrate our wiki to GitHub; this will allow us to offload functionality from the main ZF website, and also consolidate all development-related functionality (other than the mailing list) in a central location.

In this article I'll show the solution to a common problem which arises when a developer has to create a non-English website or application that is based on the Zend Framework. How do we mark a field of a Zend_Form which is a Zend_Form_Element as invalid, showing one or more custom error messages? The problem is mainly caused by the native counter-intuitive methods of the Zend_Form_Element class which I'll explain in more details.

He's included a basic example showing the creation of a form and the setup of a text element and some validators to match. He makes a controller and view to handle the output and submission then shows how to use "setErrors" (and "setErrorMessages") of the Zend_Form elements to setup that custom error. This only lets you set one message, though, regardless of the point of failure. To stop things when there's an error, you have to set the "breakChainOnFailure" parameter on the validator to false - then the message will make more sense.