XCache vs eAcc?

Discussion in 'General' started by yulia, May 7, 2009.

  1. yulia

    yulia Active Member

    Right now I'm using XCache in a suEXEc/CPanel setup for shared hosting, and just wanted to know if eAcc would be better?
  2. mistwang

    mistwang LiteSpeed Staff

    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.
  3. ezpnet-ss

    ezpnet-ss Member

    What php release have you tested this to work well with George?

  4. mistwang

    mistwang LiteSpeed Staff

    I am not exactly sure, as the problem seems related to amount of script being cached. Or, maybe the eAccelerator optimizer causes trouble for latest PHP? Not sure.
  5. yah00

    yah00 New Member

    Is this correct for eAcc?

    tmpfs /dev/shm tmpfs defaults 0 0

  6. mistwang

    mistwang LiteSpeed Staff


    create /dev/shm/eaccelerator/ directory with mode 777, this is for PHP suEXEC .
    Last edited: Dec 3, 2009
  7. MikeDVB

    MikeDVB Well-Known Member

    I have been looking into xcache and eaccelerator - how has it been working out for you guys?
  8. anewday

    anewday Moderator

    I have zero issues with eaccelerator so far.
  9. robfrew

    robfrew Well-Known Member

    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.

  10. mistwang

    mistwang LiteSpeed Staff

    Xcache is not recommended for shared hosting using suEXEC as it does not have a shared on disk storage.

    If you want to use the latest PHP release, eAccelerator may not be up-to-date, just be cautious.
  11. IrPr

    IrPr Well-Known Member

    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
  12. mistwang

    mistwang LiteSpeed Staff

    We recommend eAcc + /dev/shm , theoretically, it is in a HDD, but actually is in memory.
    Right now, PHP suEXEC starts standalone PHP process individually, so the in memory cache cannot be shared at all.
  13. robfrew

    robfrew Well-Known Member

    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?
  14. mistwang

    mistwang LiteSpeed Staff

    Maybe a permission issue?
    try start lsphp process with "sudo -u <user_name> ./lsphp5 -i" see if you get any error.
  15. robfrew

    robfrew Well-Known Member

    I just changed all of the VH's to use the main server LSAPI and everything works now. Not sure if it faster than Xcache or not yet, still analyzing.
  16. Bono

    Bono Well-Known Member

    @robfrew you are running Xcache with PHP suEXEC enabled?
  17. robfrew

    robfrew Well-Known Member

    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.
  18. Bono

    Bono Well-Known Member

    Yea you can't run it with suExec, but i'm checking maybe you have figure something out. I will wait for final XCache 1.3 version, so far 1.2.2 works very nice.
  19. auser

    auser Super Moderator

    Guess maybe cross-process lock problem?
    From one of APC developer's blog:
    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)
  20. annoumure

    annoumure Guest

    XCache vs eAcc

    Well first of all its
    Code:phpizeand 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.

Share This Page