XCache vs eAcc?

[IrPr]

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

[mistwang]

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.

[robfrew]

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?

[mistwang]

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

[robfrew]

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.

[Bono]

@robfrew you are running Xcache with PHP suEXEC enabled?

[robfrew]

Originally Posted by Bono

@robfrew you are running Xcache with PHP suEXEC enabled?

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.

[Bono]

Originally Posted by robfrew

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.

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.

[auser]

Originally Posted by robfrew

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/

The really hard part of APC is the internal locking code it has - it's not that hard to do, just hard to figure out if you've done it wrong. And I'm just about to really mess around with the assembly spin locks and pthread mutex locks to make them cross-process locks which live in shared memory (remember that "volatile" keyword in C?). The other couple of lock modes are already cross-process and slow (because of the syscall). If these work right, I won't really have to cripple the fast part of the code to implement the features I have in mind.

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)

Well first of all its
Codehpizeand 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.