eaccelerator vs apc

hostingguy · **Joined:** Mon Oct 29, 2007 6:51 pm **Posts:** 606

Hello,

I was wondering which one gives better performance? I've heard that APC does, and both of these are available from atomic, although neither one really seems to have been updated much in the last year.

I also am not sure of pear, isnt it a potential security risk to have it arround?
What do you guys use and why?

scott · **Posted:** Wed Mar 07, 2012 6:37 pm

APC is marginally better than eaccelerator, and I just did updates a few weeks back. We're using it on a particular customer site with 100 million users (only 8 systems required!)

Not that APC was the super performance secret sauce on that one. It helped, eaccelerator did too. APC edged it out by about 5%.

hostingguy · **Joined:** Mon Oct 29, 2007 6:51 pm **Posts:** 606

Is it worth having to install pear (and not being able to update easily since popen is disabled by asl by default) and having those outdated packages for only a 5% increase?
I'm not a huge fan of having to update things outside of yum when it comes to php stuff.

breun · **Posted:** Thu Mar 08, 2012 4:05 am

AFAIK you don't necessarily need to install APC via PEAR. Atomic has a package called php-pecl-apc with a prebuilt APC module.

Both eAccelerator and APC are great *when they don't cause problems*. Sometimes some particular scripts will throw the weirdest of errors when either of these is present. Usually the first thing we do when troubleshooting weird PHP errors is disabling eAccelerator/APC and this helps surprisingly often, sadly.

hostingguy · **Joined:** Mon Oct 29, 2007 6:51 pm **Posts:** 606

php-pear is a dependency that gets installed with apc

Quote:

==============================================================================================================================================================================================================================================
Package Arch Version Repository Size
==============================================================================================================================================================================================================================================
Installing:
php-pecl-apc x86_64 3.1.9-2.el5.art atomic 118 k
Installing for dependencies:
php-pear noarch 1:1.7.2-2.el5.art atomic 420 k

Transaction Summary
==============================================================================================================================================================================================================================================
Install 2 Package(s)
Upgrade 0 Package(s)

breun · **Posted:** Thu Mar 08, 2012 12:22 pm

Ok, but you don't need to keep APC up-to-date yourself, that will be handled by the RPM package via yum. I guess the package actually handles the building of the APC module via PEAR for you, but I haven't looked into that.

hostingguy · **Joined:** Mon Oct 29, 2007 6:51 pm **Posts:** 606

Right, but isnt having pear arround at all (and the default modules that it installs, which are out of date) a security risk?

Code:

# pear list-upgrades
WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
pear.php.net Available Upgrades (stable):
=========================================
Channel      Package          Local          Remote         Size
pear.php.net Archive_Tar      1.3.2 (stable) 1.3.9 (stable) 17.7kB
pear.php.net Console_Getopt   1.2.3 (stable) 1.3.1 (stable) 4.4kB
pear.php.net PEAR             1.7.2 (stable) 1.9.4 (stable) 290kB
pear.php.net Structures_Graph 1.0.2 (stable) 1.0.4 (stable) 30kB
pear.php.net XML_RPC          1.5.1 (stable) 1.5.5 (stable) 32kB
WARNING: channel "pecl.php.net" has updated its protocols, use "channel-update pecl.php.net" to update
Channel pecl.php.net: No upgrades available

And since asl lists popen and pclose as disabled php functions, you cant update these using pear upgrade-all unless you enable them really quick - which means you have one extra step to do in a daily maintenance or update scheme.

scott · **Posted:** Thu Mar 08, 2012 1:42 pm

I definitely wouldnt be using pear to update the system on an enterprise box.

hostingguy · **Joined:** Mon Oct 29, 2007 6:51 pm **Posts:** 606

I wouldnt either, but I guess my question is really more in the line of - is it ok to install and have pear on your system in the first place, especially along with those items that it seemingly installs with it which are out of date. Does even having it on the system pose a risk?

paulie · **Joined:** Tue Apr 20, 2010 2:49 am **Posts:** 74

Lurching almost back on topic we used to use eaccelerator then replaced it with xcache (which atomicorp doesn't provide an rpm for, hint hint).

We found that its pretty much as breun said, they're great when they work and eaccelerator provided the best speed for us, but xcache provides the best stability. We also primarily host Magento, and thats incompatible with later versions of eaccelerator which was the primary motivation for the change. My personal preference is for APC, but the atomic rpm's have always caused immediate crashes for us, we either compile by hand using pecl or use Jason Litka's rpms.

I did some testing between APC and Xcache that at the time I thought would be useful to add to Scott's other testing of Apache et al, but I don't think it was that scientific and I didn't like the results (Xcache faster than APC till you remove open_basedir, then APC is as fast as Xcache which barely benefits - thats probably indicative of something bad!).

Paul.

scott · **Posted:** Sat Mar 10, 2012 10:21 am

Were using the packages from the repo on that 100-million user site. That being said, the impact of the opcode compilers on magento (horrible horrible slow code) was pretty.... well.... meh. The biggest impact on it was really fixing all the slow SQL (updates, inserts) going on behind the scenes.

I'd be happy to go over the whole design if anyone is interested.

BruceLee · **Posted:** Sat Mar 10, 2012 1:27 pm

I prefer APC. eaccelerator caused to many errors for me.
BTW APC is "planned" to be integrated in next PHP version if I remember correctly.

Anyway.. something partly offtopic but someone from our turtle-community might be interested in this.
http://code.google.com/p/vitess/

Quote:

The main goal of the vitess project is to provide servers and tools to facilitate scaling of MySQL databases for the web. The Project Goals page has more details on this.

Vtocc is the first usable product of vitess. It acts as a front-end to MySQL providing an RPC interface that accepts and transmits SQL commands. It is capable of efficiently multiplexing a large number of incoming connections (10K+) over a small number of db connections at reasonable throughput (~10kqps). It also has an SQL parser which gives the server the ability to understand and intelligently reshape the queries it receives.

Vtocc is already being used in a large scale production environment. It is the core of YouTube's new MySQL serving infrastructure.

paulie · **Joined:** Tue Apr 20, 2010 2:49 am **Posts:** 74

scott wrote:

Were using the packages from the repo on that 100-million user site. That being said, the impact of the opcode compilers on magento (horrible horrible slow code) was pretty.... well.... meh. The biggest impact on it was really fixing all the slow SQL (updates, inserts) going on behind the scenes.

I'd be happy to go over the whole design if anyone is interested.

Is that for the 100 million user site or for magento? Either way I'd be pretty interested!

scott · **Posted:** Wed Mar 14, 2012 4:42 pm

Yup, its magento. Its 8 systems, 2 db, 5web, 1 lb. It uses a mix of varnish, memcached, ramdisks, apc, and some other odds and ends.

The biggest single gain comes from fixing bad SQL inside magento itself. I cannot recommend debug level query logging & lots of careful code analysis enough. Nothing will make as big an impact as that will.

eaccelerator vs apc

Who is online