Many PHP developers, myself included often mention that using PHP that is compiled statically (Apache module) is much (18-30%) faster then the shared module that is normally compiled. This is a rather unusual claim that is often met with much skepticism for a good reason, presense of pic code resulting from a shared build should not cause this, however benchmarks speaks for themselves. Unfortunately finding hard data is rather hard since most of us are rather lazy to spend 30 mins performing the needed tests. Fortunately, George Schlossnagle published the benchmarks he conducted on the matter that conclusively demonstrate that the the static build is much faster. The raw benchmark data can be found here At this time PHP still does not have a no-pic option, so for those of you interested in getting a fair bit of performance from PHP here are the instructions. When building PHP for Apache 1, make sure to configure PHP as a static Apache module and disable the building of CGI and CLI, you will also need...

This afternoon an interesting problem came to my attention. This problem is the result of PHP and mod_perl being used together on Apache server. The full details of the problem can be found [url=http://www.phpbuilder.com/lists/php-install/2003092/0018.php]here[/url]. The quick summary is that if PHP code uses putenv() function it will conflict with mod_perl and cause frequent crashes. The suggested solution is to use the Apache's apache_setenv() function. However, as I found out this does not always work. In my case I need to set the TZ environment variable that allows me to change the timezone. The tricky thing about timezone changes is that after TZ is changed, a libc function tzset() needs to be called to activate the change. PHP's own putenv() calls this function if it detects that the TZ environment variable is being changed, Apache SAPI function apache_setenv() does not. This means that the environment var change does not accomplish the desired goal. Even if I were to modify (tried doing this) the P...

A few years ago PHP developers decided to address a problem not their's to solve by implementing a configuration directive called safe_mode. To those unfamiliar with this wondrous invention, this setting is primarily intended to provide file access limits to prevent users from accessing files that do no belong to them. This supposedly should make it impossible to access files of other people in a shared server environment, a common operating environment for PHP where PHP runs as an Apache module and as such has read access to all files accessible by the webserver regardless of the owner. When enabled, safe_mode will perform a uid/gid (user id and group id) check on the file/directory to be accessed and compare it to the uid/gid of the script that is trying to access the file. If the two match then the file operation will proceed as normal and in all other cases it will fail. In theory this is a fairly simple hack to a problem that is not otherwise easily addressed without significant performance penalties suc...

There are a number of tricks that you can use to squeeze the last bit of performance from your scripts. These tricks won't make your applications much faster, but can give you that little edge in performance you may be looking for. More importantly it may give you insight into how PHP internals works allowing you to write code that can be executed in more optimal fashion by the Zend Engine. Please keep in mind that these are not the 1st optimization you should perform. There are some far easier and more performance advantageous tricks, however once those are exhausted and you don't feel like turning to C, these maybe tricks you would want to consider. So, without further ado... 1) When working with strings and you need to check that the string is either of a certain length you'd understandably would want to use the strlen() function. This function is pretty quick since it's operation does not perform any calculation but merely return the already known length of a string available in the zval structure (in...

Ever wonder what it takes to crash PHP, well here is a quick guide ;-). Technically speaking PHP being a high level language should not crash, but reality speaks for itself. By knowing what could make PHP crash it may be possible to implement various safety mechanisms in your PHP configuration that would prevent users from crashing your PHP. This is quite important since a crash is not only a 'bad thing' [tm] in general but can also have several adverse affect on the web server potentially creating a possibility for a local DOS (Denial of Service). So without further ado here is the current crash list: Stack overflow. PHP does not have any internal stack protection choosing to rely upon the system stack without any protection. This means that if you have a recursive function or a method PHP will eventually crash. function a() { a(); } a(); There are 2 solutions to this problem, 1 avoid using recursive functions they are generally a bad idea anyway, and if you MUST use them implement some counter using...