Has anyone comparied php improvements between the two php accelerators eAccelerator and APC, and which would be best for my hardware configuration (below)?
I currently have eAccelerator installed and have adjusted the keepalive to 5. What other settings should I consider?
This is a test server [absolute barebones hardware wise: PIII-800MHz 40 gigHD w/ 256MB ram running Edubuntu (currently at run level 5), Apache2, PHP5.1.6, MySQL, Moodle 1.6.2 (although I could have swore I installed 1.7!!).
... ok ... no responses yet. This small fry must not interest anyone from the standpoint of being a minimalistic system. Let me add that there will be less than 30 users at any one given time, and I've enabled as many options as possible ... and that I've got eAccelerator running.
Ralph
Although it has not been updated recently, take a look at this (http://www.ipersec.com/index.php?q=en/bench_ea_vs_apc).
Ken
Ken,
Thanks for the link, interesting reading. For reference sake:
Per their article benchmarks eAccelerator is a good choice. Granted their review was submitten in May 06, I wonder if the APC folks managed to increase the efficency of their code? At the moment I'm comfortable to stay with eAccelerator. I would like to comment that while the article states a php accelerator is essential for a high traffic site, I feel it is proving essential for a site with limited hardware resources too.
Thanks for the link, interesting reading. For reference sake:
Conclusion
The tests we did showed us there can be an important performance gain by using a PHP accelerator. Using a PHP accelerator seems essential for a high-traffic site.
But PHP accelerators are no panacea : if your code is slow, it will stay slow even with apc, eAccelerator or Zend.
Choosing an accelerator depends on your criteria :
- if you can pay for Zend, and need an official support, use Zend Platform,
- if you don't, eAccelerator is a good choice.
Each tool has advantages and drawbacks, the only way to know which one is the best at handling your code is to test both.
If, as I did, you choose eAccelerator (in order not to spend a dime on it, and to be able to change your files whenever you want), I would advise you not to get too much tied to eAccelerator, you might have to switch to apc in the future...
Per their article benchmarks eAccelerator is a good choice. Granted their review was submitten in May 06, I wonder if the APC folks managed to increase the efficency of their code? At the moment I'm comfortable to stay with eAccelerator. I would like to comment that while the article states a php accelerator is essential for a high traffic site, I feel it is proving essential for a site with limited hardware resources too.
I greatly appreciate everyone’s replies. Today was the first day I've really gotten to see how my pitiful hardware conglomeration would fair; surprisingly enough it hummed right along. For this first attempt at loading the server I didn't allow the students to use chat while taking a quiz and I remained out of any reports. There didn't appear to be any delays in serving pages or compiling results (I'd like to point out that I'm doing this over an adsl line with only 384Kbs up). Moodle is rock’n along now!
I'm going to make my pages a bit more complicated with additional graphics and some audio and video embedded.
Can someone share their settings for eAccelerator (please include load demographics)? ... I'd like to scale it to my situation.
Thanks!
Search around this forum for maxclients , maxrequestsperchild and keepalives 
There's good info to ensure your setup handles load spikes gracefully.
I used APC but only because I found a good set of step-by-step installation instructions for Ubuntu before I found anything for eAccelerator. I have been very happy with apc - it made a huge difference. I was pleased with what was working and have not tried eaccelerator - I am not sure if any comparisons have been done. I suspect it really does not matter which one you use - as long as you are using a cache you are saving the processor a lot of work and will likely get a significant performance boost. I am running: Ubuntu Linux (6.06), Apache 2.0.55, PHP 5.1.2, MySQL 5.0.22 with apc version 3.0.12p2. We average 250,000 hits per day, and over 65 cache requests per second. The most requested files from the cache have been:
/lib/setuplib.php
/lib/setup.php
/lib/adodb/drivers/adodb-mysql.inc.php
/lib/adodb/adodb.inc.php
/lib/adodb/adodb-time.inc.php
/lib/adodb/adodb-iterator.inc.php
/config.php
/lib/weblib.php
/lib/typo3/class.t3lib_div.php
/lib/typo3/class.t3lib_cs.php
/lib/textlib.class.php
/lib/moodlelib.php
/lib/filterlib.php
/lib/datalib.php
/theme/standardlogo/config.php
/lib/setuplib.php
/lib/setup.php
/lib/adodb/drivers/adodb-mysql.inc.php
/lib/adodb/adodb.inc.php
/lib/adodb/adodb-time.inc.php
/lib/adodb/adodb-iterator.inc.php
/config.php
/lib/weblib.php
/lib/typo3/class.t3lib_div.php
/lib/typo3/class.t3lib_cs.php
/lib/textlib.class.php
/lib/moodlelib.php
/lib/filterlib.php
/lib/datalib.php
/theme/standardlogo/config.php
I have experienced one error with Moodle and apc that I consider to be likely an apc issue. It has to do with exporting the gradebook or exporting things in general to excel. I call it the biff_writer error. It seems to resolve itself when I touch the file and force apc to recache it. I suspect it may have something to do with the usage of $this but I am not enough of a programmer to now for sure. In any case, I did want to at least mention it. Peace.
We're using eAccelerator on all of our PHP boxes here. I can't exactly give a figure about how much faster it is, I would say it's definitely faster. Our PHP/MySQL boxes are hit pretty heavy (28 MySQL queries per second, 500,000+ PHP requests a day). PHP eAccelerator makes those pages dish out quite a bit faster.
Also, I have a virtual dedicated server from GoDaddy, and it runs PHP eAccel. I have a Moodle installation on there, and the page loads are tremendously improved.
I can't compare APC to eAccel (i've never tried APC), but I can certainly vouch for eAccel's stability and speed.
Also, I have a virtual dedicated server from GoDaddy, and it runs PHP eAccel. I have a Moodle installation on there, and the page loads are tremendously improved.
I can't compare APC to eAccel (i've never tried APC), but I can certainly vouch for eAccel's stability and speed.
I'd recommend eaccelerator/turckmmcache. In fact, Moodle 1.8 has a new caching mechanism that makes use of eaccelerator's internal shared memory cache
Martin - Do you know if APC is still slated for inclusion with PHP6?
No idea. If it does ship with PHP6 I do hope it gets to be at least as good as the others. I suspect Zend may not want to ship PHP with a strong contender to their own precompiler/accelerator.
At the recent Dallas PHP Users Group (dallasphp.org) meeting, I continued to hear talk about apc being included with PHP6. Moodle seems to be moving more toward memcache or eaccelerator especially with some of the options in 1.8. Will similar options be available for tweaking with APC?
Turkmmcache/eAccelerator have a shmem facility in addition to the caching of precompiled PHP code -- I added those options to Moodle take advantage of the shmem functions in single-server setups (on load-balanced scenarios, use memcached).
I was going to write "APC doesn't have any shmem store/add/delete facility" but a quick check of http://au2.php.net/apc lists apc_add(), apc_store(), apc_delete() and apc_fetch(). Maybe I just didn't know about them -- anyway, it'd be trivial to use them.
In any case, the main advantage of APC/Turck/eAccelerator is their caching of precompiled PHP code. The shmem-based query cache that I wrote is an extra -- and is not applicable to every situation. Use it only of you can see demonstrable advantage. In other words, in XX% of the cases it results in _worse_ performance, in YY% it results in better performance.
cheers!
I was going to write "APC doesn't have any shmem store/add/delete facility" but a quick check of http://au2.php.net/apc lists apc_add(), apc_store(), apc_delete() and apc_fetch(). Maybe I just didn't know about them
In any case, the main advantage of APC/Turck/eAccelerator is their caching of precompiled PHP code. The shmem-based query cache that I wrote is an extra -- and is not applicable to every situation. Use it only of you can see demonstrable advantage. In other words, in XX% of the cases it results in _worse_ performance, in YY% it results in better performance.
cheers!
i did test both accelerators:
APC is very good!
eAccelerator is good enough...
APC is very good!
eAccelerator is good enough...
With Moodle 1.8 do you know if turckmmache is needed? ... or does 1.8 have it's own internal cache?
No cache is needed in 1.8. You can read up on the gory details of when it's a good idea to use the new record cache, how eaccelerator/turckmmcache/memcached can help or slow things down... here http://moodle.org/mod/forum/discuss.php?d=61418
eAccelerator is an easy install. One thing that I noticed is that it runs much faster when you put the cache in a tmpfs/memfs filesystem.
On Ubuntu:
mount -t tmpfs /dev/tmpfs /tmp
or put it in your /etc/fstab
/dev/tmpfs /tmp tmpfs 0 2
make sure that you create the directory for eaccelerator each time you reboot your system. (Not often I hope) I would add the commands to your apache startup script.
mkdir -p /tmp/eaccelerator
chown www-data.www-data /tmp/eaccelerator
On Ubuntu:
mount -t tmpfs /dev/tmpfs /tmp
or put it in your /etc/fstab
/dev/tmpfs /tmp tmpfs 0 2
make sure that you create the directory for eaccelerator each time you reboot your system. (Not often I hope) I would add the commands to your apache startup script.
mkdir -p /tmp/eaccelerator
chown www-data.www-data /tmp/eaccelerator
I made a correction from my last post on my Ubuntu server. I modified /tmp/eaccelerator to /var/tmp/eaccelerator. Leaving It in /tmp may cause unknown side-affects to other programs. (Too small of tmp size for my comfort level)
On Solaris /tmp mounted swapfs and is it correct to put the files into /tmp/eaccelerator.
YMMV,
Mikel
On Solaris /tmp mounted swapfs and is it correct to put the files into /tmp/eaccelerator.
YMMV,
Mikel
Argg...missed the 30 minute mark. Now I have to be clever all over again!
On Solaris /tmp is mounted swapfs and is it correct to put the eaccelerator files into /tmp/eaccelerator. You will have to remake the directory after a reboot.
In linux tmpfs can be used in the same way, either on /tmp or elsewhere.
See: http://www-128.ibm.com/developerworks/library/l-fs3.html
My updated task is now.
On Ubuntu:
mkdir /var/tmp/eaccelerator
sudo chown www-data.www-data /var/tmp/eaccelerator
sudo mount -t tmpfs tmpfs /var/tmp/eaccelerator
In your php.ini, change this line to:
eaccelerator.cache_dir="/var/tmp/eaccelerator"
Now put it in your /etc/fstab:
tmpfs /var/tmp/eaccelerator tmpfs defaults 0 0
And restart Apache:
sudo /etc/init.d/apache2 restart
You now don't have to recreate the /var/tmp/eaccelerator directory after the reboot, and the tmpfs will automount.
If you are VERY clever, then you might copy the cached files off of the tmpfs when apache stops and copy the cached files back on when apache starts.
While tuning this I got a %75 decrease of page time and %80 decrease of memory usage. (I also had a database issue from the old perspective.php script)
My courses page takes 0.368522 secs and RAM: 3.9MB
Your milage may vary,
Mikel
On Solaris /tmp is mounted swapfs and is it correct to put the eaccelerator files into /tmp/eaccelerator. You will have to remake the directory after a reboot.
In linux tmpfs can be used in the same way, either on /tmp or elsewhere.
See: http://www-128.ibm.com/developerworks/library/l-fs3.html
My updated task is now.
On Ubuntu:
mkdir /var/tmp/eaccelerator
sudo chown www-data.www-data /var/tmp/eaccelerator
sudo mount -t tmpfs tmpfs /var/tmp/eaccelerator
In your php.ini, change this line to:
eaccelerator.cache_dir="/var/tmp/eaccelerator"
Now put it in your /etc/fstab:
tmpfs /var/tmp/eaccelerator tmpfs defaults 0 0
And restart Apache:
sudo /etc/init.d/apache2 restart
You now don't have to recreate the /var/tmp/eaccelerator directory after the reboot, and the tmpfs will automount.
If you are VERY clever, then you might copy the cached files off of the tmpfs when apache stops and copy the cached files back on when apache starts.
While tuning this I got a %75 decrease of page time and %80 decrease of memory usage. (I also had a database issue from the old perspective.php script)
My courses page takes 0.368522 secs and RAM: 3.9MB
Your milage may vary,
Mikel
Both /tmp and /var/tmp have very relaxed permissions. That means that an unprivileged user could use this cache of executable code as a privilege escalation path. (Unlikely, but still...)
The correct thing from a FHS point of view is to use /var/cache/eaccelerator and set it to be owned by the apache user, and mode 0600 -- this is what Debian does.
The other thing to note is that eaccelerator has controls to say how much of the precompiled files it will cache in memory. The on-disk files are for precompiled files that fell out of the memory cache (I think eAccelerator has a cheap LRU algorithm to purge pages), and for persistence across apache restarts.
My recommendation would be to NOT use a tmpfs as it mucks up the reasonably efficient approach of eaccelerator, and to make sure /var/cache/eaccelerator is on a partition mount with noatime,async and that the journaling mode is set for performance.
(This post brought to you by pedantic day )
The correct thing from a FHS point of view is to use /var/cache/eaccelerator and set it to be owned by the apache user, and mode 0600 -- this is what Debian does.
The other thing to note is that eaccelerator has controls to say how much of the precompiled files it will cache in memory. The on-disk files are for precompiled files that fell out of the memory cache (I think eAccelerator has a cheap LRU algorithm to purge pages), and for persistence across apache restarts.
My recommendation would be to NOT use a tmpfs as it mucks up the reasonably efficient approach of eaccelerator, and to make sure /var/cache/eaccelerator is on a partition mount with noatime,async and that the journaling mode is set for performance.
(This post brought to you by pedantic day
It figures that I was optimizing backwards!
I'm going to fix it as soon as I can. Thanks for the correction!
Mikel
I'm going to fix it as soon as I can. Thanks for the correction!
Mikel
Im using APC, so far so good... performance OK...
Im planning to experiment eaccelerator if performance is better?
Im planning to experiment eaccelerator if performance is better?
I would be very interested in your experimentation with eAccelerator. It is hard to know which to go with. Moodle seems to be moving toward better integration with eAccelerator while php (at least from the rumor mill) seems to moving toward incorporating APC. I have been very pleased with APC with the exception of the error I have occasionally seen with exporting excel files - I refer to it as the Biff_Writer error (with Moodle 1.6+).