4 replies to this topic

[Alexander]

Before you read:

My previous article about PHP optimization at the coding level can be located here: http://forum.codecal...y-practise.html

I would recommend reading it and applying those strategies to get the most performance out of your PHP applications, this step will help on the hardware end lowering resource usage on Apache/Lighttpd children processes.

The differences can be shown greatly when compared to plain PHP execution when working with a large framework or PHP script.

Drupal 6 with Apache:[/left]
	   Maximum RAM used (MB) / Average request time (ms) / Requests per second

No acceleration: 29MB / 94ms / 44 requests
eAccelerator:	  22MB / 34ms / 140 requests
APC:           25MB / 39ms / 141 requests

As can be seen, APC and eAccelerator both improve the response of the Drupal-run website immensely.

OpCode Caching:

From eAccelerator.net:

Quote

eAccelerator is a free open-source PHP accelerator & optimizer. It increases the performance of PHP scripts by caching them in their compiled state, so that the overhead of compiling is almost completely eliminated. It also optimizes scripts to speed up their execution. eAccelerator typically reduces server load and increases the speed of your PHP code by 1-10 times.

This step in optimizing your applications can be crucial for performance if your applications are larger and require higher resources per viewing, in the example above Drupal was used to prove its usefulness on a high traffic website. Anything from a file index, to Wordpress can improve in speed by storing the resulting compiled cache for later use.

Downloading:
First you must understand if you have the PHP 5 development tools, this can be checked by typing phpize anywhere in the console:

phpize -v

If this command runs you may skip this step, otherwise you can safely download it to your distribution with the following command(s):

Debian/Ubuntu:		 sudo apt-get install php5-dev
RHEL/CentOS/*SUSE:	 yum install php-devel
Gentoo:				emerge php5-dev
Arch Linux:			pacman -S php5-dev

Once you confirm Apache/PHP's development tools are installed you may download the latest source of eAccelerator, this current package:

cd /tmp
wget http://downloads.sourceforge.net/project/eaccelerator/eaccelerator/eAccelerator%200.9.6.1/eaccelerator-0.9.6.1.zip?r=&ts=1338242122&use_mirror=iweb

You will then be required to unzip the archive, this can be achieved with the command unzip:

unzip eaccelerator-(version number)
cd eaccelerator-(version number)

Once you are within the eAccelerator folder, we will run the phpize command to configure the module according to your Zend and PHP versions:

phpize
./configure --enable-eaccelerator=shared

This enables eAccelerator to utilize shared memory and configures it to your system specifications as well. We are then done setting it up, you can build and install the library and application as so:

make
sudo make install

Installing into PHP 5:

During the "make install" processes the directory of which your PHP module was installed to will be listed at the bottom, note this directory for the next few steps so PHP can access the library.

We will now be editing php.ini so check where yours is located, most likely "/etc/php5/apache2/php.ini". Having trouble? Look at the phpinfo(); function output for the location.

And edit it with your favourite editor. You can skip to the bottom of the file and add the following lines as you like:

zend_extension				  = "/usr/lib/php5/20100613+lfs/eaccelerator.so"
eaccelerator.shm_size		   = "0"
eaccelerator.cache_dir		  = "/var/cache/eaccelerator"
eaccelerator.enable			 = "1"
eaccelerator.optimizer		  = "1"
eaccelerator.check_mtime		= "1"
eaccelerator.debug			  = "0"
eaccelerator.filter			 = ""
eaccelerator.shm_max			= "0"
eaccelerator.shm_ttl			= "0"
eaccelerator.shm_prune_period   = "0"
eaccelerator.shm_only		   = "0"
eaccelerator.compress		   = "1"
eaccelerator.compress_level	 = "7"

Notice our zend_extension directory, be sure to replace the first part with where your eaccelerator.so file is actually located as noted before. Once this is done we can restart apache 2 through any of the commands you were given, they may be one of these two:

httpd restart
(or)
apache2ctl restart

Assuming they did correctly restart without error, you may now create a page with the command phpinfo() in it. It can look like this:

<?php
	phpinfo();
?>

Be sure to remove the phpinfo page after you had verified its installation.

Note: Instructions should be given to you in the download for the above settings, however they often do not need to be changed and remain between versions. The shm_ttl option set to 0 will allow the kernel option "/proc/sys/kernel/shmmax" dictate the maximum size before cached scripts are purged from the cache folder, this can default from 3-5 megabytes per process.

Assuming the module had loaded up correctly, scrolling down to the Zend/PHP version area in phpinfo(); it should state eAccelerator is installed!

This ends my CodeCall tutorial.

Edited by Alexander, Today, 02:00 PM.
Formatting migration to IPB

[John]

What is the difference between eAccelerator and Hip Hop for PHP (by Facebook)?

[Alexander]

John said:

What is the difference between eAccelerator and Hip Hop for PHP (by Facebook)?

Hi, eAccelerator or APC both optimize intermediate code and usually store it in shared memory for faster re-execution, Hip Hop essentially is a static code analyzer (lexer) that lexically converts PHP code as C++ compatible form, often in its own wrapped executable package that can be ran by the server. They both can be utilized to reduce CPU usage overheard of PHP execution where CPU is nearly always the bottleneck in servers.

[Mechanician]

Thanks for the notes! I have a teeny-tiny virtual server with only 256MB of RAM, which means it might not be a good idea for me to use eAccelerator, right? How should I evaluate whether to use it or not?

[Alexander]

Hey Machanician, 256 megabytes of RAM is fine for a small server, and caching will automatically take up the appropriate amount of shared memory as per your Linux kernel configuration.

You can actually look at the benifits like this, caching may be 30 or so megabytes total when under load, but each large dynamic script ran can take up no shared memory overhead at all when viewed by different people, as its compiled code is already in a single cache.