XCache vs eAcc?
- Thread starter yulia
- Start date
With suEXEC PHP, each PHP process has its own cache memory, it wastes a lot of memory if many PHP process running. It is true for all opcode caches.
eAcc store cache on disk, we thought it is a good idea to put the disk cache under /dev/shm, make it effectively an in memory cache shared by all PHP processes, however, eAcc causes high load for some users, maybe due to bug with certain PHP release.
So, we do not have a perfect opcode cache solution working really well for shared hosting. If the bug in eAcc has been fixed, it will get our recommendation.
eAcc store cache on disk, we thought it is a good idea to put the disk cache under /dev/shm, make it effectively an in memory cache shared by all PHP processes, however, eAcc causes high load for some users, maybe due to bug with certain PHP release.
So, we do not have a perfect opcode cache solution working really well for shared hosting. If the bug in eAcc has been fixed, it will get our recommendation.
Is this correct for eAcc?
/etc/fstab
tmpfs /dev/shm tmpfs defaults 0 0
extension="eaccelerator.so"
eaccelerator.shm_size="150"
eaccelerator.cache_dir="/dev/shm"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="3600"
eaccelerator.shm_prune_period="1800"
eaccelerator.shm_only="1"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
eaccelerator.keys="shm_only"
eaccelerator.sessions="shm_only"
eaccelerator.content="shm_only"
/etc/fstab
tmpfs /dev/shm tmpfs defaults 0 0
extension="eaccelerator.so"
eaccelerator.shm_size="150"
eaccelerator.cache_dir="/dev/shm"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="3600"
eaccelerator.shm_prune_period="1800"
eaccelerator.shm_only="1"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
eaccelerator.keys="shm_only"
eaccelerator.sessions="shm_only"
eaccelerator.content="shm_only"
Xcache works great with our setup. It's blazing fast. And it also works with the latest releases of PHP such as 5.3. The fact that they are keeping up with the latest releases tells me they are constantly making Xcache better.
If you look at various sites that have done testing on both, they say that eA and Xcache are pretty much neck in neck when it comes to performance.
http://trentadams.com/2008/05/22/xcache-and-eaccelerator/
If you look at various sites that have done testing on both, they say that eA and Xcache are pretty much neck in neck when it comes to performance.
http://trentadams.com/2008/05/22/xcache-and-eaccelerator/
If you are using Enterprise version and binded listeners on more than one core, then the same issue with suExec which George described in 2nd post would be happened to xCache memory storage
It will spawn multi proccess which leads to multi shared memory storages, which will recude performances using xCache
So if you want to use xCache its better to bind listeners to one core only
BTW im using xCache without suExec and one core binded to listener
Ofcourse RAM I/O is very faster than HDD, so using RAM as cache storage will boost PHP scripts more than HDD
Seems a trade off between RAM and HDD I/O performances and security to me
It will spawn multi proccess which leads to multi shared memory storages, which will recude performances using xCache
So if you want to use xCache its better to bind listeners to one core only
BTW im using xCache without suExec and one core binded to listener
Ofcourse RAM I/O is very faster than HDD, so using RAM as cache storage will boost PHP scripts more than HDD
Seems a trade off between RAM and HDD I/O performances and security to me
EA has released an svn version that is supposed to be compatible with PHP 5.3. We tried testing it the other day, and it seemed to work great on our main sites. But then, one of our clients notified us that their site wasn't accessible, he was getting 503 errors. So we checked, and every site that we added using the PHP_suexec VH template wasn't working. We checked the logs and LSWS wasn't creating the php .sock files in the /tmp directory for each VH. So that tells me that PHP won't load with eA module enabled, but just for those particular sites.
It's weird because it works for the two main sites that use their own external app configurations.
So we had to remove eA and put back XCache and things are running smoothly again.
Not sure why eA won't start and causes PHP not to load on the other VH's. Any ideas?
It's weird because it works for the two main sites that use their own external app configurations.
So we had to remove eA and put back XCache and things are running smoothly again.
Not sure why eA won't start and causes PHP not to load on the other VH's. Any ideas?
No, we have full control of our server so we do not need to run suExec. Not sure if you can run Xcache with it according to mistwang.
As a note to anyone trying to run the latest svn of eAcc with PHP 5.3, we tested it out and after about 4 hours of running, our load averages were hitting 200.00. After review, our lsphp processes looked like they were hanging with about 6% cpu usage and new ones were being created. Not sure why this was happening but we had to remove eAccelerator to make it stop. We have not had any problems with XCache and PHP 5.3 so far.
As a note to anyone trying to run the latest svn of eAcc with PHP 5.3, we tested it out and after about 4 hours of running, our load averages were hitting 200.00. After review, our lsphp processes looked like they were hanging with about 6% cpu usage and new ones were being created. Not sure why this was happening but we had to remove eAccelerator to make it stop. We have not had any problems with XCache and PHP 5.3 so far.
Guess maybe cross-process lock problem?
From one of APC developer's blog:
http://t3.dotgnu.info/blog/tags/apc/
Another APC developer @facebook has demo to compare several lock method's performance.
Here's his blog:http://tekrat.com/
the detail is in the excellent slides:http://prezi.com/135715/ (as mentioned in Jul 24,2009 blog)
From one of APC developer's blog:
http://t3.dotgnu.info/blog/tags/apc/
Another APC developer @facebook has demo to compare several lock method's performance.
Here's his blog:http://tekrat.com/
the detail is in the excellent slides:http://prezi.com/135715/ (as mentioned in Jul 24,2009 blog)
A
XCache vs eAcc
Well first of all its
Code
hpizeand not phpsize.
I am curious why do you need X-Cache? Are you sure thats the thing you need for your hosting?
About Apache issues, you are trying to install them from yum. You need to install xcache from source, otherwise you will make a mess in your system.
Well first of all its
Code
hpizeand not phpsize.I am curious why do you need X-Cache? Are you sure thats the thing you need for your hosting?
About Apache issues, you are trying to install them from yum. You need to install xcache from source, otherwise you will make a mess in your system.