2008-08-26 48 views
56

Estoy tratando de mejorar el rendimiento con mucha carga y me gustaría implementar el almacenamiento en caché de código de operación. ¿Cuál de los siguientes debería usar?¿Qué código de operación de código PHP debo usar para mejorar el rendimiento?

también estoy abierto a otras alternativas que se han deslizado bajo mi radar.

Actualmente se ejecuta en un archivo de Debian Etch con Apache 2 y PHP 5.2

[Actualización 1]

enlaces instalación HowtoForge añadido

[Actualización 2]

Based sobre las respuestas y comentarios recibidos, probé las 3 implementaciones usando el siguiente plan de prueba Apache JMeter en mi aplicación:

  • sesión
  • Acceso Home Page

Con 50 conexiones simultáneas, los resultados son los siguientes:

Sin Código de Operación de almacenamiento en caché
No Opcode Caching

APC
APC

eAccelerator
eAccelerator

XCache
XCache

gráfico de funcionamiento (más pequeño es mejor)
Performance Graph

De los resultados anteriores, eAccelerator tiene una ligera ventaja en rendimiento en comparación con APC y XCache. Sin embargo, lo más importante de los datos anteriores es que cualquier tipo de almacenamiento en caché de código de operación da un impulso tremendo en el rendimiento.

que han decidido utilizar APC debido a las siguientes 2 razones:

  • paquete está disponible en el repositorio oficial de Debian
  • panel de control más funcional

Para resumir mi experiencia:

Facilidad de instalación: APC> eAccelerator> XCache
Rendimiento: eAccelerator> APC, XCache
Panel de control: APC> XCache> eAccelerator

+0

¿Por qué está esto cerrado? – Pacerier

+0

¡APC tiene algunos problemas, como restablecimiento de la conexión! – Abadis

+0

@Pacerier La definición de lo que está * en el tema * ha cambiado a lo largo de los años, por lo que este "se convirtió" fuera del tema. – James

Respuesta

16

Creo que la respuesta puede depender del tipo de aplicaciones web que esté ejecutando. Tuve que tomar esta decisión yo mismo hace dos años y no pude decidir entre Zend Optimizer y eAccelerator.

Para tomar una decisión, utilicé ab (apache bench) para probar el servidor y probé las tres combinaciones (zend, eaccelerator, ambas en ejecución) y comprobé que eAccelerator por sí solo ofrecía el mejor rendimiento.

Si tiene el lujo del tiempo, le recomendaría hacer pruebas similares y tomar la decisión en función de sus resultados.

+0

¿Por qué no se menciona HipHop? – Pacerier

+1

Porque HipHop no es un caché de código de operación ni existía cuando se formuló esta pregunta. – BlaM

3

He tenido un buen éxito con eAccelerator (la mejora de velocidad sin carga es notable) pero XCache también parece bastante prometedor. Es posible que desee ejecutar algunos ensayos con cada uno, su aplicación puede escalar de manera diferente en cada uno.

1

He estado usando XCache durante más de un año sin problemas.

Traté de cambiar a eAccelerator, pero terminé con un montón de fallas de segmentación (es menos tolerante a los errores). El principal beneficio de eAccelerator es que no es solo un caché de opcode, sino también un optimizador.

Debe probar completamente su aplicación con cada uno de ellos para asegurarse de que no haya ningún problema, y ​​luego usaré apachebench para probarla bajo carga.

5

He corrido varias benchmarks with eAcclerator, APC, XCache, y Zend Optimizer (aunque Zend es un optimizador, no un caché).

Benchmark Results http://blogs.interdose.com/dominik/wp-content/uploads/2008/04/opcode_wordpress.png

Resultado: eAccelerator es más rápida (en todas las pruebas), seguido de XCache y APC. (El que está en el diagrama es la cantidad de segundos para llamar a una página de inicio de WordPress 10,000 veces).

Zend Optimizer hizo todo más lento (!).

1

Estos complementos han introducido históricamente muchos errores extraños para rastrear. Estos errores pueden causar un comportamiento incoherente que no se puede diagnosticar fácilmente porque depende del estado de la memoria caché.

así que diría:

  1. No utilice cualquiera de los anteriores. Compre más estaño en su lugar, es una manera más confiable (es decir, sin errores) de aumentar el rendimiento. O
  2. Vaya con cualquiera de los anteriores es el más robusto, después de haber probado los pantalones de su aplicación.

Pero diría:

  1. Asegúrese de que sea realmente PHP análisis de código que está causando sus problemas de rendimiento mediante el perfilado su aplicación. Creo que es muy probable que no lo sea, en cuyo caso estarías perdiendo el tiempo (en realidad, utilizando tu tiempo de forma negativa y productiva) al instalar cualquiera de ellos.
+0

Podemos usar algunos de ellos para almacenar en caché los datos. Por ejemplo, APC es capaz de almacenar en caché tanto los datos como el código de operación. pero realmente estoy de acuerdo con tu última oración: "Asegúrate de que sea REALMENTE el análisis de código PHP el que está causando tus problemas de rendimiento" – Abadis

Cuestiones relacionadas