Makes sense. And you don’t need to recompile PHP and Apache to do it! Here is a snippet:
PHP is a scripting language most often used to create Web applications. It’s easy to learn and produces visible results quickly. However, because PHP is interpreted, PHP code is parsed and translated to opcodes every time it executes. An opcode cache eliminates that rework, making PHP applications faster.
In a short time, PHP has become a popular programming language for Web applications. For the beginner, PHP is simple to install and easy to learn. For the more experienced developer, it (as of V5) offers robust object-oriented features. The community of PHP developers is enormous, and a significant number of open source and commercial libraries and tools extend the capabilities of the core language. PHP is favored by so many because it produces visible results rapidly.
Much like other scripting languages used for Web applications, including Perl, Python, and Ruby, PHP code is parsed, translated to opcodes (primitive instructions — akin to assembly language — that the PHP engine executes directly), and executed each and every time an HTTP request summons it. For negligible and low demand, your server executes this complex rendering process seemingly instantly. But as the number of pages served increases, interpretation — in essence, rework — can tax the system. In some cases, the “compilation” of your PHP code can far exceed the time required to execute the code. Hence, as demand grows, you can readily become a victim of your own success, as serving more dynamically interpreted, dynamically generated pages requires more and more resources.
If your site had an unlimited budget for processors and RAM, you’d likely never have to optimize your application stack (hardware, operating system, database, Web server, and PHP code) to keep your site responsive. However, because money is typically the scarcest of resources, tweaking for performance is inevitable. Tuning might mean adding memory to a starved system, modifying operating system parameters, hastening the Web or database server, rewriting code for efficiency, or some combination thereof. Each can contribute to gains.
Don’t burn cycles — Recycle
Yet another way to conserve CPU cycles is simply to reduce the amount of rework required to run your PHP application. Certainly, there is no need to translate the same PHP code each time. After your PHP code has been translated into opcodes, it can be saved and reused again and again — until the original code is modified. Indeed, caching — saving and reusing the intermediate PHP code, the opcodes — is the idea behind several PHP accelerators, including the open source Alternative PHP Cache (APC), Turck MMCache for PHP, XCache, eAccelerator, and the commercial Zend Platform. The latter three cache and optimize the byte code, providing for even greater speedups.
This month, let’s explore how to install, deploy, and configure XCache. XCache is a relative newcomer, but many sites are reporting good results with it. In addition, it is easy to build, install, and configure because it’s implemented as a PHP extension. Recompiling Apache and PHP isn’t required.
This article is based on XCache V1.2.0. It reliably supports PHP V4.3.11 to V4.4.4, PHP V5.1.x to V5.2.x, and early versions of PHP V6. (XCache doesn’t support PHP V5.0.x.) XCache works with mod_php and FastCGI, but not with the Common Gateway Interface (CGI) or the command-line PHP interpreter. The XCache source code builds on a variety of systems, including FreeBSD, Sun Solaris, Linux®, and (as shown here) on Mac OS X. XCache can be built on Microsoft® Windows®, as well, using the Cygwin UNIX® emulation environment or Visual C. You can build XCache for Cygwin or for native Win32. The latter target is compatible with the official Win32 release of PHP.
twitter.com/wenbert