Kevin Schroeder has posted the results of some research he did around using the "AllowOverride" setting in Apache. He found some interesting differences when it was set to "all".

Commonly known as .htaccess, AllowOverride is a neat little feature that allows you to tweak the server's behavior without modifying the configuration file or restarting the server. [...] Beyond the obvious security problems of allowing configuration modifications in a public document root there is also a performance impact. What happens with AllowOverride is that Apache will do an open() call on each parent directory from the requested file onward.

He includes the output from a strace call in the post - first showing the function calls with it set to "none" then the same request with the setting on "all". More "open" calls are being made in the second run, increasing the execution time by a decent amount.

Harrie Verveer has a new post to his blog today looking at some benchmarking numbers he's run on the performance difference Xdebug (the popular PHP debugger) would have on a production system.

Normally this tool would be used on your development environment, or in rare occasions on some remote environment that is similar to the production environment. [...] Since you are adding extra overhead it is very likely things will run slower. But how significant is this difference. Would it be something worth considering?

To lay the ground work, he describes the hardware he's running the tests on and the software he used - PHP 5.2.6 (Suhosin) on Debian with Xdebug 2.1.0 - and the script he used to run the tests. Several tests were run multiple times (3) showing quite a difference in performance when using the debugger versus not. He also suggests a more practical testing scenario with WordPress and ApacheBench. The numbers still support the other results.

In a side note, the Twitter account for Xdebug has mentioned some updates that have been made to the version currently on their SVN server that can help with some of these performance issues.

Kevin Schroeder has a recent post to his blog about a handy trick Zend Framework developers can use to have Zend_Log write out to multiple sources at once pretty easily.

If you were not aware, Zend_Log provides facilities for writing to multiple logs through the same log instance. Additionally, you can do this via configuration options when using a Zend_Application resource plugin. Together those make for very powerful logging mechanisms. "How?" you ask? It's really easy.

The trick lies in the application.ini file configuration. He includes an example of how you can set this up showing how to make two different environments log differently - development writes to log/firebug and production just writes to the log. He includes some sample code for a basic controller showing you how to use it.

In an interesting post to his blog Kyle Brandt asks a question universally debated by system administrators everywhere - should developers have access to production?

A question that comes up again and again in web development companies is: 'Should the developers have access to the production environment, and if they do, to what extent?' My view on this is that as a whole they should have limited access to production. A little disclaimer before I attempt to justify this view is that this standpoint is in no way based on the perceived quality or attitude of the developers '" so please don't take it this way.

He talks about common excuses from developers like "we've had access before" and "we need access to troubleshoot" as well as some of the process restricting the access could create. He touches on a few other issues including developer concerns vs those of the sysadmin, change control issues and the responsibilities of the sysadmin administrators if they want to allow the developers to poke around their servers.

Be sure to check out some of the other great suggestions in the comments too!

Setting up and using the Magento e-commerce application can be a difficult process in itself, but when you start moving things around from server to server, things can get even more complex. In this new post from the Godaddyhostingreview blog they talk about moving a Magento instance from your local install out to a live site.

This is the method I used to move my local copy of magento store from WAMP on windows to a shared hosting account. In my case am using magento1.3.x.

The instructions are detailed right down to which configuration values to change, how to update your database for the move, what will need to be removed before you and push everything over. There's even a bit of instruction on what to change if your database structure is slightly different.

Cal Evans has posted the first part of his look at DTAP - development, testing, acceptance and production - and how it applies to PHP development.

There are four primary systems that need to be set up and isolated. And they are described by the acronym DTAP-Development, Testing, Acceptance, and Production. One thing that has changed recently, though, is that these systems no longer have to mean separate hardware.

He gives an overview of each, setting out definitions to be used for the rest of the series with the next part discussing some of the "smaller moving pieces" of the process.

Christopher Jones has noted that the latest version of the OCI8 drivers for PHP (in the PECL extension) have been pushed to the current stable package.

HP's OCI8 1.3.3 has support for Oracle's DRCP connection pooling and Fast Application Notification technologies giving it improved scalability and high availability. Overall, the re-architecture of the connection code is more stable. It fixes some obscure edge case issues and lets it handle re-started DB's better. Basic functionality is unchanged.

You can find out more about the package and download this latest edition from its PECL page or check out the whitepaper they recent;y wrote up about PHP and Oracle scalability.

In a response to this post on the PHP 10.0 Blog, Richard Heyes offers a method for what Stas was wanting:

OK, then what we do if something weird happens in production and we want to see the errors, but we don't want others to see them? [...] Maybe PHP could have some setting like display_errors=local which would enable display_errors for requests originating from developer machine but would disable it when outsider accesses it?

Richard's solution checks the HTTP_HOST value of the current request and, based on whether it's marked as "live" or "dev", uses a ini_set to change the display_errors setting to true/false.

Since he didn't come across any issues or bug reports, Richard Heyes has officially released his SMTP class for PHP5 as "out of public beta" and ready for production use.

I've not added any new features to the class; I've simply updated it to be, well, better. Plus it uses PHP5's object model better. It's really just an update, ie if you're using the old version and it works, then you have no real reason to update it.

You can check out the source here and an example of it in action here.