Most interpreted programming languages parse source files and translate/compile them into opcode/bytecode that are suitable to be executed in the virtual machine. Python for example, dumps the compiled opcode into the .pyc or .pyo files so when the same file is imported again in the future, no parsing and compilation needs to be done. On the other hand plain vanilla PHP does not really have a way to save cached opcode so that at every request, source files have to be parsed and compiled into opcode again and again.

So we have the PHP accelerators which are mostly opcode cachers + optimiser, which cache the compiled opcode to either memory or disk, so the scripts don’t need to be parsed and compiled again in subsequent requests. They greatly improve the performance, and even the up-coming PHP6 will have the APC built in by default.

Being able to run PHP scripts and applications is probably one of the most obvious feature in shared web hosting today, but the actual process to make it fast and secure at the same time might not be that trivial.

I am actually writing this post in response to this thread at WHT, where web hosts discussed ways to fight back against those 200Gb oversold plans that are populating the shared hosting industry today. That thread went off-topic half way through when Matt Heaton of BlueHost and Kevin Martin of Pair Networks had a not-so-friendly discussion on whether to run PHP as CGI or as mod_php on servers.

I had a problem with Lighttpd and PHP on the default Gentoo install. The configuration that comes with Gentoo, and the “official recommendation” use bin-ath in the mod_fastcgi to point to PHP’s CGI executable.