Posts Tagged ‘eaccelerator’

Howto install XCache Debian on GNU / Linux to accelerate Apache Webserver – XCache Best alternative to outdated PHP cacher EAccelerator

Thursday, February 26th, 2015

I was using Eaccelerator until recently on all Apache / PHP / MySQL  (LAMP) web-servers as a caching engine (Webserver accelerator) across all Debian GNU / Linux Lenny / Squeeze / Etch servers.
However recently, I've noticed in phpinfo output on some of the Debian hosts, that eaccelerator was loaded but showed:

 Caching Enabled false



Our servers are quite busy serving about 50 000 to 100 000 requests and thus not having enabled caching puts a lot of extra load on the CPU and eats a lot of memory which were usually saved by eAccelerator.
Logically I tried fixing the issues following some Stackoverflow threads recommendations such as this one but didn't work I tried playing manually spending hours trying to make eaccelerator run again and as a final mean, I even tried to upgrade eaccelerator to newer version but noticed the latest available eaccelerator version 0.9.6 was 2.5 years old (from 03.09.2012). Thus while there is no new release, just make s so just to make sure I didn't break the module with (default Debian bundled distribution package which is also installed on the servers)  re-installed eAccelerator from source 

This didn't worked either and since I was totally pissed off by the worsened systems performance (CPU load increased with to 10-30%) per server, I looked for some alternatives I can use and in the mean time I learned a bit more about history of PHP Accelerators, I learned some interesting things such as that  ionCube (PHPA) was the  first PHP Accelerator Apache like module (encoding PHP code),  created in 2001, later it become inspirational for  birth to PHP-APC (Alternative PHP Cache) Apache module. 
There is also Zend Opcache PHP accelerator (available since PHP 5.5 onwards)  but since Zend OpCache caches well PHP Zend written PHP code and servers run PHP 5.4 + sites are not using Zend PHP Framewosk  this was an option.
Further investigation lead me to MMCache which is already too obsolete (latest release is from 2013), PHPExpress – PHP Encoder which  was said to run on Windows, Linux, FreeBSD, NetBSD, Mac OS X, and Solaris) but already looks dead as there were no new releases since January 2012) and finally Lighttpd's XCache.

To give you an idea on what exactly is the difference between Apache Webserver with PHP-APC Caching or other PHP Cacher enabled and the Standard way PHP Interprets PHP scripts below is a diagram:


Obviously my short research shows that from all the available PHP Cache Encoder / Accelerators only ones that seemed to be recently updated (under active development) are APC and XCache.
I've already used PHP-APC earlier on some servers and was having having some random Apache Webservers crashes and weird empty pages with some PHP pages and besides that APC is known to give lower speed in PHP caching than Eaccelerator and XCache, leaving me with the only and logical choise to use XCACHE.

Here is how Xcache developers describe their opcacher:

XCache is a free, open source operation code cacher, it is designed to enhance the performance of PHP scripts execution on servers. It optimizes the performance by eliminating the compilation time of PHP code by caching the compiled version of code into the memory and this way the compiled version loads the PHP script directly from the memory. This will surety accelerate the page generation time by up to 5 times faster and also optimizes and increases many other aspects of php scripts and reduce website/server load.


Thanksfully XCache is shipped by default with all Debians (Etch /Lenny / Squeeze / Wheezy)  Linuces so to install it just run the standard apt cmd:

apt-get install –yes php5-xcache

Then to enable XCache all I had to do is edit /etc/php5/apache2/php.ini and place below code

debian-server:~# vim /etc/php5/apache2/php.ini


;; install as zend extension (recommended), normally "$extension_dir/"
;;zend_extension = /usr/lib/php5/20100525/


xcache.admin.enable_auth = On
; Configure this to use admin pages
; xcache.admin.user = "mOo"
; xcache.admin.pass = md5($your_password)
; xcache.admin.pass = ""

; ini only settings, all the values here is default unless explained

; select low level shm/allocator scheme implemenation
xcache.shm_scheme =        "mmap"
; to disable: xcache.size=0
; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size  =                16M
; set to cpu count (cat /proc/cpuinfo |grep -c processor)
xcache.count =                 1
; just a hash hints, you can always store count(items) > slots
xcache.slots =                8K
; ttl of the cache item, 0=forever
xcache.ttl   =                 0
; interval of gc scanning expired items, 0=no scan, other values is in seconds
xcache.gc_interval =           0
; same as aboves but for variable cache

Note that Debian location which instructs xcache to load in Apache as a module is xcache.ini – e.g. /usr/share/php5/xcache/xcache.ini, so instead of placing above configuration right into php.ini you might prefer to place it in xcache.ini (though I personally prefer php.ini) because it is easier for me to later control how PHP behaves from single location.

To test whether XCache is enabled for Apache Webserver:

Create phpinfo.php somewhere in DocumentRoot (in my case this was /var/www/php_info.php)

debian-server:~# vim /var/www/php_info.php



When you access the php_info.php in browser you will get XCache loaded as in below screenshot:



To Test whether Xcache is enabled also for PHP CLI (applications set to run as a crontab – cronjob) :

debian-server:~# php -v
PHP 5.4.37-1~dotdeb.0 (cli) (built: Feb  2 2015 05:03:00)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
    with XCache v3.2.0, Copyright (c) 2005-2014, by mOo
    with XCache Cacher v3.2.0, Copyright (c) 2005-2014, by mOo


Once it is tested as successful install you might want to enable the XCache admin (which is disabled by default), to enable XCache Admin on Debian you need to generate new password for it first like so:


echo -n "xcache_rulez" | md5sum


Then you need to add in /etc/php5/mods-available/xcache.ini

debian-server:~# vim /etc/php5/mods-available/xcache.ini
xcache.admin.enable_auth = On
; Configure this to use admin pages
 xcache.admin.user = "admin"
; xcache.admin.pass = md5($your_password)
 xcache.admin.pass = "change_with_above_generated_password_here"


To enable admin and be able to access it in a browser (if you're using as a documentroot /var/www/ and docroot supports interpretting php scripts and (has AllowOverride All) enabled to also support htaccess authentication do:

debian-server:~# cd /var/www/
debian-server:~# ln -sf /usr/share/xcache/htdocs/ xcache

When you access you should see in browser some statistics along with all configured xcache options:


If you have time you can play with the options and get some speed minor speed improvements. The overall increase in page opening XCache should give you is between 100% – 190% !

Enjoy 🙂

Install Eaccelerator PHP cacher to decrease server CPU load on Debian Squeeze GNU / Linux

Monday, December 3rd, 2012

eaccelerator a php opcode cache optimizer accelerator

I don't know what is happening with Apache but I'm quite disappointed with the poor performance results  of  Apache2.2.16-6+squeeze8  + PHP 5.3.3-7+squeeze14 – installed from Official Debian Squeeze repositories through debs (apache2-mpm-prefork and libapache2-mod-php5). I should say the Apache is mainly processing PHP part of my wordpress blog which of time of writting contains about 1280 posts, few joomla based sites, another little wordpress and few other very little projects written in PHP The daily unique visitors the host gets are not that high about 8000 UNIQUE IP visitors and besides that the machine is equipped with a good amount of memory running on Lenovo PowerEdge host, here is raw system config where I got issues:

System Memory: 8 GB
Dual Core Intel(R) Pentium(R) CPU G630 @ 2.70GHz (5.40 Ghz), with
CPU  cache size    : 3072 KB.

The machine is not too powerful for a server configuration but for about 8000 Unique visitors mostly fetching WordPress pages many of which are cached with W3 Cache WP Plugin and handled back to the client in plain .html it is unusual such Apache CPU overloads happens. It is true the incoming traffic from crawlers puts a high load on the system as some of the WebCrawlers like 80legs sometimes are fetching pages too agressive and therefore create too high loads from PHP code multiple times interpreted by Apache, it is also a fact that sometimes the machines gets a bunch of increased number of requests from normal User IPs, but still the traffic even in peak hours  should not so high to be causing the weird Apache forked childs CPU overloads.

I've used Eacceleartor in the past and it proofed to significantly reduced the load Apache puts on servers CPU on all servers installed . Thus I thought of experimenting and running Eaccelerator on those particular problematic Debian Squeeze host to see if this will make some difference and fully resolve problems or at least reduce the overloads frequency. Whether this weird Apache overloads happens the system load avarage drops often to 80 or 100! The host is completely lagged then and often inaccessible via ssh. The work around is  either manual Apache restart via Apache init script (/etc/init.d/apache2 restart) or be setting a script to automatically restart Apache whether high load is matched. In some cases, the system gets so loaded that even the automated shell script which does restart Apache on high loads is not working, so only fix is to manually do cold system reset.

Eaccelerator though mostly popular among server administrators and thoughmany of the eaccelerators installs are on Debian  as of time of writting in Debian stable Linux does standard repositories does not include it . In past on Debian Lenny I used to  install Eacceleartor using a 3rd party repository but as I tried following my own tutorial to install it from deb without compiling I've figured out eaccelerator .deb's are no longer available.

Thus I proceeded and install it from source, here is how;

1. First to compile eacceleator from source one needs to have installed few build tools


 apt-get install --yes php5-dev make

2. Second download it from eaccelerator source repo on github, untar, compile, create eaccelerator cache directory, create eaccelerator config and restart Apache to load new settings.

 cd /usr/local/src

 wget -q
 mv master eacceleartor.tar.gz

 tar -zxvvf eaccelerator.tar.gz
drwxrwxr-x root/root         0 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/
-rw-rw-r-- root/root       204 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/.gitignore
-rw-rw-r-- root/root       670 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/AUTHORS
-rw-rw-r-- root/root     17992 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/COPYING
-rw-rw-r-- root/root     49163 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/ChangeLog
-rw-rw-r-- root/root       627 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/Makefile.frag
-rw-rw-r-- root/root       269 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/
-rw-rw-r-- root/root      9761 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/NEWS
-rw-rw-r-- root/root     17053 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/PHP_Highlight.php
-rw-rw-r-- root/root      7281 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/README
-rw-rw-r-- root/root      2760 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/README.win32
-rw-rw-r-- root/root      2634 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/bugreport.php
-rw-rw-r-- root/root      9235 2012-08-16 16:34 eaccelerator-eaccelerator-42067ac/config.m4

cd $(ls -ld *eaccel*/|awk '{ print $9 }')  phpize
 make install
 mkdir -p /var/cache/eaccelerator
 chmod 0777 /var/cache/eaccelerator
 cd /etc/php5/conf.d/

echo 'extension=""' >>  eaccelerator.ini
echo 'eaccelerator.shm_size="16"' >> eaccelearator.ini
echo 'eaccelerator.cache_dir="/var/cache/eaccelerator"' >> eaccelerator.ini
echo 'eaccelerator.enable="1"' >> eaccelerator.ini
echo 'eaccelerator.optimizer="1"' >> eaccelerator.ini
echo 'eaccelerator.check_mtime="1"' >> eaccelerator.ini
echo 'eaccelerator.debug="0"' >> eaccelerator.ini
echo 'eaccelerator.filter=""' >> eaccelerator.ini
echo 'eaccelerator.shm_max="0"' >> eaccelerator.ini
echo 'eaccelerator.shm_ttl="0"' >> eacceleartor.ini
echo 'eaccelerator.shm_prune_period="0"' >> eaccelerator.ini
echo 'eaccelerator.shm_only="0"' >> eaccelerator.ini
echo 'eaccelerator.compress="1"' >> eaccelerator.ini
echo 'eaccelerator.compress_level="9"' >> eaccelerator.ini


/etc/init.d/apache2 restart

For some clarity here is the exact config placed in /etc/php5/conf.d/eaccelerator.ini by above echo commands


People who are lazy to copy paste from this post and like to have eaccelerator installed updated to a number of hosts (e.g. do some scripting automation) use tiny shell script. script is very useful for people who regularly update Debian to latest security updates.
Due to the fact eaccelerator is compiled from source code, after every update of Apache or PHP packages it is necessery to rebuild also eaccelerator, otherwise after upgrading Apache eaccelerator will stop silenty working, so if you don't explicitly check in phpinfo(); periodically you might even not have noticed that, except if you don't notice a bit of degraded performance after the last Apache / PHP update. Actually the need to re-compile eaccelerator PHP module, after each Apache or PHP update is a bit annoying and is downsize, that package has no native deb. There is one work around to that I can think of – just set to execute via cron routinely.
 I personally don't do that but people, as I don't like full automation, but people who prefer to install once eaccelerator and further forgot about it should:

a. Copy script to lets say /usr/local/bin

b. set a cronjob similar to

10 5,10,15,20,25,27 * * * /usr/local/bin/ >/dev/null 2>&1

During execution the cron would put some extra load on the system but at least, you can be sure you will regularly be running with working / updated (re-compiled) version of Eaccelerator.

To test if eaccelerator is loaded on the system check in phpinfo(); function output. Create anywhere in a site DocumentRoot a file like php_info.php with content:


Access the site in browser and look for eaccelerator in it. If eaccelerator is configured to serve well you will see something like on below screenshot:

eaccelerator php cache engine debian squeeze screenshot

Install eacceleartor php load up info debian squeeze linux shot
One note to make here is Eaccelerator might be creating problems due to caching on some hosts using Smarty Framework for a site basis, I assume with some other PHP Frameworks there might be some problems too but in general due to my experience so far I've faced problems with sites due to eaccelerator in very rare occasions in maybe 50 Eaccelerator installs so far, there were issues due to caching only on maybe 2 or 3. However I should share Eaccelerator is not recommended on testing Apace + PHP server for web development, as on those it sometimes might be creating "dev. time lags" in development due to caching – a common example for that is when a developer substitutes a .php with another similar ones whose size is identical to the previous .php script ….

After installing the system load dropped a bit, there is plenty of benchmarking online comparing Eaccelerator with other popular PHP Cachers like XCache, APC, PurePHP etc. – According to benchmarking done between the 3 Eaccelerator is maybe the most fastest PHP Cacher  – the article is a bit outdated but worthy to read.
As a result of putting in use Eaccelerator now the system load is more gracefully distributed in time sar (system activity information) over time does not show moments in which the CPU was "stoned" idling at 0 – as before.

As a result of the resolved downtimes and Apache restarts, I see also in webalizer statistics increase in the amount of traffic (unique visitors). Only time will show for sure if this increased capacity of traffic serving is directly because of Eaccelerator or there were other factors too but as long as I didn't change nothing else on the host I think it is very likely it is thanks to Eaccelerator.
Another note to make here is that on PHP Zend Framework it might be Zend PHP Caching via APC is quicker than Eaccelerator.

P.S. : Sometimes you might need to clean Eacceleartor PHP Cache, as it might be cause for showing old cached pages; even though some PHP were updated – more n that here

I will be glad to hear from people who install Eaccelerator, some feedback, did you got decreased server loads and more stable and quicker served pages?

I would like to also to give thanks to this nice blog article which was along the articles which help me with install guideance and hence was a kind of inspiration of this a bit prolonged but hopefully informative article.

After all, increased "Apache thoroughput" and more served connection without changing (spending on new hardware) is way to increase ur business efficiency and save money 🙂

Njoy 😉

How to solve “eAccelerator requires Zend Engine API version 220060519 , the Zend Engine API version 220090626 which is installed, is newer. Contact eAccelerator at for a later version of eAccelerator.” on FreeBSD

Monday, April 4th, 2011

I’ve recently upgraded my FreeBSD Apache server from port www/apache20 I had some issues before I tune up and recompile also the php5 port but eventually it worked out, however the Eaccelerator content caching module failed to load as it was outdated.

That’s a common inconvenient with eaccelerator that every system administrator out there has faced once or twice, especially on systems that has custom compiled Apache servers and does not use a specific precompiled version of the eaccelerator.

To solve the situation as you can expect I jumped on in the /usr/ports/www/eaccelerator and removed the current installed version of eaccelerator in order to compile and install the latest port version.:
To do that I first attempted to upgrade the eaccelerator port with portmaster but as there were some problems caused by autoconf initialization etc., I finally decided to abandon the idea of using portmaster and did it manually with the good old well known trivial commands:

freebsd# cd /usr/ports/www/eaccelerator
freebsd# make deinstall
freebsd# make install && make clean

I’ve continued further and restarted my Apache server to load the new eaccelerator version and made a small phpinfo php script to test if the eaccelerator is properly loaded, yet with zero success.

After checking out in my /var/log/httpd-error.log , I’ve determined the following error:

Failed loading /usr/local/lib/php/20060613/ Cannot open "/usr/local/lib/php/20060613/"

The error is quite obvious, to solve it I’ve opened my php configuration file /usr/local/etc/php.ini and placed in it:

and substituted the line:




Further on I gave Apache another restart with:

freebsd# /usr/local/etc/rc.d/apache2 restart
Performing sanity check on apache2 configuration:
Syntax OK
Stopping apache2.
Waiting for PIDS: 71140.
Performing sanity check on apache2 configuration:
Syntax OK
Starting apache2.

followed by another test if the eaccelerator is loaded with the phpinfo(); script.

Now even though the Failed loading /usr/local/lib/php/20060613/ Cannot open “/usr/local/lib/php/20060613/” was no more, the Eaccelerator was yet not loaded.

Another consult with /var/log/httpd-error.log now revealed me another eaccelerator error you read below:

eAccelerator requires Zend Engine API version 220060519.
The Zend Engine API version 220090626 which is installed, is newer.
Contact eAccelerator at for a later version of eAccelerator.

I did about 20 minutes of investigation on the internet looking for a possible fix which gave me some idea what might be the cause for error message, though it was finally my try/fail methodology that helped me solve the issue.

The solution to the issue appeared to be easy thanks God, to solve the error all you need to do is one more make clean right before installing the eaccelerator port.:
Here are the commands necessary to issue to solve the error and make the eaccelerator load properly:

freebsd# cd /usr/ports/www/eaccelerator
freebsd# make clean &&
freebsd# make install clean

Now after restarting the Apache server once again eaccelerator has properly been loaded once again.


Thursday, December 13th, 2007

A great improvements in php execution times may be achived using the eaccelerator php module it keeps cached the executing php filesso prevents the server from interpreting the same php files over and over again on each client visist. I recommended itto everyone looking for performance optimization The project is located on Today we had a HRQM lessonin the College before that we had Dutch. I went to the pharmacy to buy some medicines after school. Psychic health isa serious issue I observe I and other friends need psycho therapy :). The life is going day after day I’m curiouswhy do people need so much information. Everything has become so complex nowheredays that sometimes you can’t to makeeven the small assignments for the day. Currently I’m trying to brainwash my brain with a SCI-FI serial called “THE 4400” it’s anabsolute bull shit (nevermind). Today also there is a divine grace thanks to God. From 3 days I’m listening Saviour Machineagain heavily pretty neat band if you haven’t checked it I recommend it 🙂 There are many questions I ask myself everyday with the hope someday I’ll know them. The most general question of them is “What’s the point of all”. I think the only corrent answer everytime I found is “to walk humbly with your God” and as a result of this be more and more like Christ. Faith in God is such a strange think. You’re in him and he is in you :)END—–