Pues precisamente esa es la función de un «Acelerador de PHP», tomar el script(s) ya compilado, guardarlo en una memoria compartida y usarlo la próxima vez que se solicite este script, «compila una vez, corre muchas veces». El tiempo, y por tanto mejora del rendimiento de un servidor, depende principalmente de la complejidad de la aplicación php y memoria disponible para almacenar los scripts ya compilados.

Dada la forma en que funcionan estos «aceleradores», no en cualquier servidor se pueden instalar. Necesitas que PHP funcione como módulo de Apache (o cual sea estés usando) o enFastCGI, ya que desde CGI no va a funcionar la memoria compartida entre procesos. Apache también debe estar configurado, en el caso de usar php como módulo, para funcionar con un proceso y múltiples hilos (prefork), ya que con múltiples procesos e hilos (worker) estos aceleradores no se llevan bien, generando los odiosos mensajes “PHP has encountered an access violation at XXXXXXX”.

En un VPS con poca memoria RAM (menos de un 512MB) por la que compiten Apache y Mysql, es difícil que un acelerador pueda lograr buenos resultados junto a una aplicación grande. Yo solo los he usado en servidores dedicados con al menos un 1GB de RAM disponible.

Alternative PHP Cache (APC)

APC fue el primer acelerador que probamos con Maestros del Web, logramos bajar el tiempo de respuesta del sitio de 600ms a 400ms. APC es completamente gratuito y open source, un punto que habla muy bien de APC es que en PHP6 será incluido dentro del core de PHP.

APC incluye un script con el que puedes consultar estadísticas sobre el rendimiento de APC y el uso de la memoria, es algo que me gusta comparado con otros aceleradores:


clic para agrandar

En internet hay bastantes tutoriales de como instalar APC en diferentes entornos, para quienes usan Centos con WHM/Cpanel seguro les interesará seguir esta guía.

XCache

XCache es el segundo y actual acelerador de php que usamos con nuestros servidores, principalmente por las recomendaciones que nos dieron en el foro de optimización de servidores en vBulletin.com. Un punto a destacar de XCache es que lo ha escrito uno de los desarrolladores de Lighttpd, servidor web que tiene la fama de ser mucho más rápido al enviar contenido estático, comparado con Apache.

XCache también cuenta con un panel de control y de estadísticas, aunque comparado con el de APC es mucho menos visual:


clic para agrandar

XCache se ha ganado la fama de funcionar siempre con nuevas versiones de PHP (según dicen el soporte para PHP 5.3 ya está hecho), o al menos antes que los demás aceleradores, pero por alguna razón con PHP 5.2.6 en nuestros servidores fue demasiado inestable. Si usan Centos y WHM/Cpanel, acá está la guía que nosotros seguimos para instalar XCache.

Hablando de un comparación rendimiento entre APC y XCache, realmente no percibimos una diferencia notoria. Pero ya que los desarrolladores de vBulletin nos recomendaron más XCache, nos cambiamos a este.

eAccelerator

Nosotros no hemos probado eAccelerator en nuestros servidores, pero aún parece ser una buena opción que cuenta con bastantes seguidores. eAccelerator ya viene configurado dentro de las opciones de CPanel para Apache/PHP, para los que no quieran quebrase la cabeza instalando un acelerador desde los fuentes 😉

Es difícil decir cual de estos tres aceleradores de php es mejor, depende mucho del hardware, la configuración del software instalado y la aplicación(es) que se esté usando. Por ejemplo alguien comparó Drupal con estos 3 aceleradores y eAccelerator le funciono mejor, alguien más con Zend Framework dice que APC es mejor.

¿Cuanta memoria asignar para guardar los php ya compilados? Depende de cuantos archivos tenga tu CMS. En nuestros servidores corren varios CMS’s entre vBulletin, WordPress, MediaWiki y OpenAds; para lo que destinamos entre 60MB a 100MBs de RAM. Hay que recordar que si solo se tiene un servidor, hay que dejar memoria disponible para Apache, Mysql y el sistema operativo. Nosotros empezamos probando con 32MBs de memoria para acelerador, y la fuimos incrementando hasta que consideramos que buena parte del CMS estaba cacheado.

Estos tres aceleradores también cuentan con un espacio exclusivo para variables (datastorage), varios CMSs aprovechan este espacio para ahorrar algunas consultas a la DB almacenando allí datos bastante comunes, como las preferencias y configuraciones del gestor; a este espacio si mucho le hemos asignado unos 5MBs. Los datos del uso de la memoria del acelerador siempre pueden se consultar desde el panel de control que cada uno tiene.

Quién esté interesado en instalar un acelerador de PHP debería probar más de uno, evaluar el rendimiento y estar pendientes del error log, cada uno de estos tiene a ser inestable en diferentes formas. Con Foros del Web, si no usáramos un acelerador de php, es casi seguro que necesitaríamos un servidor extra durante los picos de tráfico.

Otras opciones

Los tres aceleradores de php que acá mencionamos no han sido los únicos que existen:

  • Zend Platform: Más que un acelerador de PHP es toda una plataforma de herramientas de optimización, caché y monitoreo para PHP. El hecho de que sea un producto comercial, lo deja fuera de mi lista de «por probar».
  • ionCube PHP Accelerator (PHPA): Fue la primera alternativa gratuita para mejorar el rendimiento de PHP, la competencia al Zend Cache (comercial) de aquel entonces. Actualmente su desarrollo fue avandonado.
  • Turck MMCache: Es el código original de donde más tarde saldría eAccelerator (como un fork de este), aún cuando hoy está descontinuado hay personas que lo siguen usando (por sistemas heredados).
  • Zend Optimizer: Otro producto no código abierto, sirve principalmente para correr aplicaciones comerciales y codificadas con Zend Guard. Incluye un optimizador de código que en teoría mejora mejora el rendimiento de las aplicaciones, pero de acuerdo a lo que he leído, tiene muchos conflictos de estabilidad con los aceleradores de php. Nadie recomienda su uso real, a menos que se tenga un script codificado.

¿Alguien ha usado uno de estos aceleradores de PHP? ¿Cuál les ha funcionado mejor con su sitio? La verdad, al final todo esto se convierte en un proceso de prueba y error.