apc vs eaccelerator vs xcache


105

Estoy investigando cuál de estos usar y realmente no puedo encontrar uno que se destaque. Eaccelerator es más rápido que APC , pero APC se mantiene mejor. Xcache es más rápido pero los demás tienen una sintaxis más sencilla.

Alguien tiene recomendaciones sobre cuál usar y por qué?


1
eAccelerator no parece que haya tenido un lanzamiento en más de un año. El VC de xcache ciertamente está activo, pero tampoco pude concentrarme en los lanzamientos y tampoco en un enfoque. Todo se reduce a una pieza de software que se mantiene y APC gana sin duda alguna.
Hasta

11
Es el tercer trimestre de 2011. ¿Han cambiado las cosas desde 2009?
juan

Respuestas:


110

APC se incluirá en PHP 6, y supongo que ha sido elegido por una buena razón :)

Es bastante fácil de instalar y ciertamente acelera las cosas.


He estado sopesando estos tres y he decidido comenzar a probar con APC por este motivo. Los otros dos también parecen tener algunos problemas de estabilidad.
Steve Claridge

46
Solo me he encontrado con tres problemas con APC, todos los cuales estaban bajo mi control. 1) No deje que el APC se llene. Asegúrese de asignar suficiente memoria 2) No use apc_clear_cache () en un servidor activo 3) APC realmente no se adapta bien a la contención de bloqueo pesado; no intente escribir en una sola clave de varios procesos simultáneamente.
Frank Farmer

10
En realidad, actualmente no existe PHP6.
Evert

20
Dado que este hilo es un resultado superior en Google, probablemente debería actualizarse para indicar que Zend Optimizer se fusionó con PHP 5.5, que se lanzó este mes. Usted puede apagarlo y el uso de APC en su lugar, aunque no estoy seguro de por qué te gustaría.
Bosque

2
El almacén de datos de @Benjamin User se puede restaurar con APCu ( github.com/krakjoe/apcu ), que se puede instalar y utilizar junto con ZO.
Swader

23

Consulte los puntos de referencia y las comparaciones:

aquí y aquí y allá


15
Lástima que sean tan viejos. 2006? Ewww.
analytik

3
¿Supongo que podemos esperar un par de años y el comentario anterior será antiguo?
benmarks

5
Éxito. Ahora tiene 3 años. Ewwww.
Swader

3
Amigo, ya es 2016. ¿Alguien puede rehacer los puntos de referencia hace una década?
Pacerier

13

APC definitivamente. Está escrito por los chicos de PHP, por lo que aunque no comparta las velocidades más altas, puede apostar por el hecho de que es de la más alta calidad.

Además, obtienes otras funciones ingeniosas que uso todo el tiempo ( http://www.php.net/apc ).


3
Facebook también es un gran usuario de APC: utilizan gigabytes, si no terrabytes, de caché de APC. Muchas de las mejoras que han realizado se han vuelto a publicar e integradas en la versión principal de APC.
Frank Farmer

13
Estás pensando en memcached.
Evert

3
@Cada FB intenta acceder a un caché APC local antes de hacer una conexión TCP / IP a memcached scribd.com/doc/4069180/…
Andy

1
Probablemente ... pero cuando habla de mejoras que se han lanzado, etc., probablemente sea Memcache. A menos que hayan hecho lo mismo con apc.
Evert

@Andy, Facebook no usa nada de esto. Utiliza su propia máquina virtual HipHop.
Pacerier

11

Al final, me decidí por eAccelerator: el aumento de velocidad, la menor huella de memoria y el hecho de que sea muy fácil de instalar me convenció. También tiene una interfaz web agradable para borrar el caché y proporcionar algunas estadísticas.

El hecho de que ya no se mantenga no es un problema para mí, funciona, y eso es todo lo que me importa. En el futuro, si rompe PHP6 (o lo que sea), entonces volveré a evaluar mi decisión y probablemente iré con APC simplemente porque ha sido adoptado por los desarrolladores de PHP (por lo que debería ser aún más fácil de instalar)


4
"si rompe PHP6" ... ¿no te refieres a "cuándo?" :)
Brian Lacy

2
Es gracioso porque, 5,5 años después, todavía no existe un "PHP 6".
Eric L.

@Eirik, PHP 6 es tan ayer. Son las 7 ahora.
Pacerier

11

Puede ser importante señalar las versiones actuales estable, inestable y dev de cada uno (incluida la fecha):

APC

http://pecl.php.net/package/apc

dev        dev          2013-09-12
3.1.14     beta         2013-01-02
3.1.9      stable       2011-05-14

Xcache

http://xcache.lighttpd.net/

dev/3.2     dev        2013-12-13
dev/3.1     dev        2013-11-05
3.1.0       stable     2013-10-10
3.0.4       stable     2013-10-10

eAccelerator

https://github.com/eaccelerator/eaccelerator

dev         dev        2012-08-16
0.9.6-rc1   unstable   2010-01-26
0.9.5.1     stable     2007-05-16

1
Últimas versiones actualizadas: Xcache parece tener la mayor actividad tanto en las funciones nuevas como en las versiones anteriores de parches
Ryan Schumacher

9

En todas las pruebas que he visto, eAccelerator funciona más rápido que cualquier otro caché y usa menos memorias para hacerlo. Viene con una secuencia de comandos ingeniosa para ver la utilización de la caché y borrar la caché, etc. eAccelerator es compatible con xdebug y Zend Optimizer.

APC se incluye en PHP porque los desarrolladores de PHP lo mantienen. Funciona muy bien, pero no tan bien como eAccelerator. Y tiene problemas de compatibilidad con Zend Optimizer.

Xcache fue creado por los desarrolladores de lighttpd, los puntos de referencia muestran que funciona de manera similar a eAccelerator y más rápido que APC.

Así que ¿cuál es el mejor?

APC = Genial si desea un caché fácil que siempre funcione con PHP, sin problemas. eAccelerator = Si tiene tiempo para mantenerlo, manténgalo actualizado y comprenda cómo funciona, funcionará más rápido. El soporte a largo plazo no es tan seguro como APC porque APC lo realizan los desarrolladores de PHP.


7

Probé eAccelerator y XCache con Apache, Lighttp y Nginx con un sitio de Wordpress. eAccelerator gana cada vez. Lo malo son solo los paquetes que faltan para Debian y Ubuntu. Después de una actualización de PHP, a menudo el servidor deja de funcionar si los módulos de eAccelerator no se vuelven a compilar.

El último RC de eAccelerator es del 15/07/2009 (0.9.6 rc1) con soporte para PHP 5.3


6

Siempre usé APC con php 5.1 y 5.2, pero tuve muchos errores (aleatorios) al usar APC con php 5.3: páginas en blanco extrañas, errores aleatorios de memoria insuficiente. Todos desaparecieron cuando desactivé APC. Pero esa no era una opción, ya que está ejecutando un sitio web de gran volumen.

Así que probé eaccelerator. Hasta ahora ha sido sólido como una roca y el aumento de velocidad es incluso mayor que con APC. Los chicos de APC realmente necesitan dedicar algo de tiempo a la corrección de errores.


1
Tuve los mismos problemas con APC y php 5.3. Gracias por el comentario. PHP sin almacenamiento en caché en mi configuración es mucho más rápido y confiable que con APC. Las páginas en blanco y los errores de memoria me estaban volviendo loco hasta que eliminé APC.
Paul D. Eden

nunca descubrí la razón por la que el kernel mata php-fpm debido a apc
vimdude

4

Creo que APC es el camino a seguir, a menos que esté utilizando Zend Optimizer en el sitio. APC es incompatible con Zend Optimizer, por lo que, en ese caso, deberá optar por algo como eAccelerator.


Si usa Zend Optimizer, no necesita nada más porque también realiza el almacenamiento en caché de código de opción y expone una interfaz compatible con APC.
txyoji

3

Incluso tanto eacceleator como xcache funcionan bastante bien durante cargas moderadas, APC mantiene su estabilidad bajo una gran intensidad de solicitud. Si estamos hablando de unos cientos de solicitudes por segundo aquí, no notará la diferencia. Pero si está tratando de responder más, definitivamente quédese con APC. Especialmente si su aplicación tiene características demasiado dinámicas que probablemente causarán problemas de bloqueo bajo tales cargas. http://www.ipsure.com/blog/2011/eaccelerator-as-zend-extension-high-load-averages-issue/ puede ayudar.



2

APC segfaults todo el día y toda la noche, no tengo experiencia con eAccelerator pero XCache es muy confiable con un montón de opciones y desarrollo constante.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.